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*•  Operations  Research,  and  Organizational  Analysis— to  assist  a task 

y-  force  commander  and  his  staff  in  tactical  planning  and  combat 

1.  decisionmaking.  In  support  of  the  ODAP,  this  report  examines  the 

problems  encountered  and  the  solutions  realized  in  previous  attempts  j 

j to  develop  operational  decision  aids  and  decision  aiding  systems. 

Among  the  systems  examined  are  the  Vessel  Traffic  System  (VTS),  the  ? 

| Standoff  Target  Acquisition  System  (SOTAS),  the  TRIDENT  Defensive 

Command  and  Control  System,  the  Simulated  Tactical  Operations  System  • 
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I.  EXECUTIVE  SUMMARY 


A.  BACKGROUND 

In  the  Operational  Decision  Aids  Program  (ODAP),  the  Office  of  Naval 
Research  is  studying  decision  aids  to  assist  a task  force  commander  and  his 
staff  in  tactical  planning  and  combat  decisionmaking.  Emphasis  in  the 
program  is  on  the  exploration  of  methodologies— drawn  from  the  fields  of 
Decision  Analysis,  Information  Science,  Operation  Research,  and  Organiza- 
tional Analysis— to  assess  their  applicability  to  support  the  task  force  com- 
mander in  his  decisionmaking  role.  The  ODAP  currently  has  prototype  oper- 
ational aids  under  development  and  a test  bed  under  construction  at  the 
Wharton  School  of  the  University  of  Pennsylvania. 

The  aids  under  development  in  the  ODAP  will  be  integrated  into  tactical 
command  and  control  systems,  with  initial  implementation  planned- for  the 
Navy's  Tactical  Flag  Command  Center  (TFCC).  ODAP  will  thus  be  confronted 
with  many  of  the  problems  associated  with  the  development  of  operational 
systems  and  With  the  incorporation  of  newly  developed  decision  aids  into  an 
existing  command  and  control  structure.  In  order  to  minimize  potential, 
problems  in  implementing  the  aids  and  to  develop  efficient  procedures  for 
conducting  the  implementation,  SPC  was  tasked  to  investigate  previous 
attempts  to  develop  operational  decision  aids  and  decision  aiding  systems. 
The  investigation  was  to  emphasize  the  problems  that  were  encountered  and 
the  solutions  that  were  realized  In  the  development  of  operational  aids. 

This  report  presents  the  results  of  that  investigation. 
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The  approach  taken  in  the  investigation  was  to  examine  a carefully 
selected  set  of  operational  decision  aids  and  decision  aiding  systems  and 
to  illustrate  by  example  the  specific  types  of  problems  that  were  encountered 
in  the  development  of  the  aids  and  the  means  that  were  found  for  resolving 
them.  Emphasis  in  the  selection  of  problems  for  detailed  investigation 
focused  on  those  which  would  be  of  greatest  value  to  the  ODAP  in  structuring 
their  program.  With  the  emphasis  in  the  ODAP  on  the  exploration  of  new 
methodologies,  this  requirement  tended  to  favor  the  selection  of  problems 
that  relate  to  the  acceptance  of  the  system  by  the  users,  although  problems 
as  diverse  as  those  relating  to  the  integration  of  a decision  aiding  system 
into  an  existing  command  and  control  structure  and  the  structuring  of  the 
software  packages  for  a decision  aiding  system  were  also  considered. 

In  the  investigation,  attention  was  also  given  to  the  identification 
of  procedures  that  successful  system  developers  follow  in.  developing  their  * 
systems.  An  awareness  of  these  procedures  should  be  helpful  to  the  ODAP  in 
avoiding  many  of  the  problems  commonly  encountered  in  the  development  of 
operational  aids.  An  attempt  was  also  made  in  the  investigation  to  obtain 
reasonably  complete  functional  descriptions  of  the  systems— both  to  provide 
the  background  necessary  for  an  appreciation  of  the  problems  under  investiga- 
tion and  to  illustrate  the  character  and  level  of  sophistication  of  current 
operational  decision  aiding  systems. 

The  principal  systems  examined  in  the  investigation  are: 

• The  Vessel  Traffic  System  (VTS).  This  system,  developed  for  the 
United  States  Coast  Guard  by  the  Applied  Physics  Laboratory  of  the 
Johns  Hopkins  University,  monitors  vessels  in  San  Francisco 
harbor  and  advises  them  of  traffic  conditions  in  the  bay.  It 
provides  an  illustration  of  a computer  aided  system  that  was 
developed  to  replace  a manually  operated,  rudimentary  system 
previously  used  for  traffic  control  in  the  bay. 

• The  Standoff  Target  Acquisition  System  (SQTAS).  -This  system, 
under  development  by  the  U.$.  Army  Electronics  Command,  assists 
the  division  commander  in  making  decisions  concerning  the  deploy- 
ment and  utilization  of  His  forces.  It  provides  an  illustration 
of  an  independently  developed  system  that  must  be  integrated  into 
an  existing  command  and  control  structure. 


-*  *~  -^^awg^aswggww^ess^gggi^ggi^g^^ 


TRIDENT/SSN  Command  and  Control.  The  defense  command  and  control 
systems  of  the  Navy's  TRIDENT  and  SSN  nuclear  submarines  provide 
an  illustration  of  the  level  of  sophistication  of  present  and 
proposed  operational  decision  aids. 


The  Simulated  Tactical  Operations  System  (SIMTOS).  This  system, 
developed  by  the  Army  Research  Institute,  is  a research  tool 
intended  to  assist  in  the  development  and  study  of  computerized 
tactical  command  and  control  systems.  It  is  tailored  to  the  study 
of  data  base  organization  and  processing,  decision  aid  evaluation, 


and  the  more  general  problem  of  human-computer  interaction  in 
tactical  Cd  systems. 


Navy  Surface  Ship  Combat  Direction  Systems.  These  systems,  which 
include  the  Naval  Tactical  Data'  System  (NTDS),  provide  informa- 
tion to  the  tactical  commander  and  his  staff  to  assist  him  in 
maneuvering  his  ship  and  employing  his  weapons  in  a combat  environ- 
ment. 


Army  Tactical  Data  Systems.  These  systems,  which  includes  the 
Tactical  Operations  System  (TOS),  provide  information  to  the 
division  commander  and  his  staff  to  assist  him  in  preparing  plans 
and  making  decisions  concerning  the  disposition  and  employment 
of  his  forces. 


Documentation  on  three  other  decision  aiding  systems  was  also  reviewed 
in  the  investigation.  The  first  two  documents— a critique  of  the  decision 
aiding  system  in  the  National  Military  Command  Center  and  a description  and 
historical  profile  of  a mythical  naval  software  system  (MUDD) — contain 
discussions  particularly  relevant  to  the  current  investigation.  The  third— 
a report  on  the  development  of  a decision  aid  to  assist  a tactical  commander 
in  attacking  hardened  air  bases— describes  an  attempt  to  use  Von  Neumann- 
Morganstern  Utility  Theory  in  assigning  tactical  aircraft  to  an  attack  on  a 
Warsaw  Pact  airbase. 


DISCUSSION 


The  level  of  mathematical  sophistication  of  the  decision  aids  under 
development  by  the  ODAP  and  the  complexity  of  the  activities  they  will 
perform  substantially  exceed  the  level  and  complexity  of  most  presently 
deployed  operational  aids.  Most  operational  aids  are  concerned  either  with 


the  automation  of  procedures  which  were  formerly  performed  manually  or  with 
relatively  simple  task  aiding,  such  as  the  SOTAS  aid  that  provides  a time- 
compressed  playback  of  data  to  assist  an  operator  In  visually  detecting  and 
tracking  enemy  activity  (see  Chapter  III).  More  sophisticated  aids— which 
permit,  for  example,  a commander  to  explore  the  consequences  of  adopting 
alternative  courses  of  action— are  also  operational  (or  near  operational). 

A TRIDENT  aid  (see  Chapter  IV),  for  example,  permits  a commander  to  explore 
the  consequences  of  adopting  alternative  tactics  for  a mobile  countermeasure. 
The  aid  does  not,  however,  possess  the  level  of  mathematical  sophistication 
of  many  of  the  aids  under  development  in  the  ODAP. 

The  Introduction  of  sophisticated  methodologies  to  assist  the  task 
force  commander  In  the  decisionmaking  process,  while  offering  the  oppor- 
tunity for  substantial  assistance  to  the  commander,  nevertheless,  gives 
rise  to  critical  problems  Involving  the  acceptability  of  the  aids  to  the 
users.  Some  members  of  the  operational  community  expressed  considerable 
doubt  that  the  approaches  under  consideration  by  the  ODAr  would  be  of 
significant  value  to  them.  Others  felt  that  the  Introduction  of  such 
methodologies  was  premature;  sufficiently  challenging  operational  problems— 
concerned  with,  for  example,  the  determination  of  what  Is  appropriate  to 
display  and  how  It  should  be  displayed— remain  to  be  resolved  before  It 
would  be  appropriate  to  consider  the  use  of  methodologies  of  the  type  pro- 
posed by  the  ODAP  (see,  In  particular,  Chapter  V). 

The  attainment  of  user  acceptance  for  the  ODAP  decision  aids  Is,  In 
our  judgment,  critical  to  the  success  of  the  program.  User  acceptance 
Impacts  the  opportunity  for  the  aids  to  receive  a fair  and  Impartial 
evaluation  within  the  community  and  ultimately  the  frequency  and  effective- 
ness with  which  the  aids  are  used  by  the  operators.  Furthermore,  In  our 
judgment,  It  Is  an  area  that  warrants  considerably  more  attention  than  It  Is 
currently  receiving  In  the  program.  Two  steps  that  would  promote  the 
acceptability  of  the  aids  are: 

• The  methodology  under  development  by  the  ODAP  should  be  "sold" 
to  the  operational  community  on  the  basis  of  a demonstrated 
capability  to  assist  the  task  force  commander  (or  his  staff) 
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to  make  better  decisions  or  to  make  them  more  quickly.  To 
conduct  this  demonstration,  the  ODAP  should  develop  near  oper- 
ational prototype  decision  aids.  These  should  possess  sufficient 
realism  In  the  eyes  of  the  user  to  provide  a credible  demon- 
stration of  the  capabilities  of  the  aids.  In  our  judgment,  this 
Is  the  best--and  quite  likely  a necessary— way  to  ensure  that  the 
decision  aids  are  favorably  received  by  the  operational  community. 

• In  developing  the  prototype  decision  aids,  the  ODAP  should  observe 
the  principle  of  "methodology  hiding"  In  structuring  the  aids. 
Methodology  hiding  Implies  that  the  Interface  between  the  system 
and  the  operator  should  comprise  only  displays  and  require  only 
operations  that  relate  directly  and  Immediately  to  the  combat 
environment  In  a way  that  an  operator  Is  accustomed  to  perceiving 
It.  Requiring  an  operator  to  develop,  compute,  or  Interpret  data 
or  Information  that  relate  to  an  abstract  framework  with  which  he 
Is  not  accustomed  to  working  substantially  reduces  the  likelihood 
that  he  will  react  favorably  to  the  system  and  ultimately  that  the 
system  will  be  successfully  employed. 

Other  approaches  that  have  been  found  In  the  development  of  decision 
aiding  systems  to  promote  the  acceptability  of  the  aids  should  also  be 
pursued  by  the  ODAP.  Numerous  examples  of  such  approaches  can  be  found  In 
the  body  of  the  report  (see,  In  particular,  Chapter  2.)  Certain  of  these— 
such  as  assuring  the  aids  present  an  attractive  physical  appearance-are 
obviously  desirable  features  to  have  In  an  aid,  but-  frequently  tend  to  be 
overlooked  In  favor  of  attention  to  technical  details  of  the  system.  Others— 
such  as  assuring  a decision  aiding  system  can  be  easily  learned  and  operated— 
require  attention  early  In  the  design  of  the  system.  Each  of  these  features, 
while  primarily  cosmetic  In  nature,  Is  extremely  Important  In  gaining  accep- 
tance of  a system;  however,  It  Is  of  such  a character  that  It  Is  often 
neglected  by  the  theoretical  researcher. 

Other  types  of  approaches,  which  are  directed  at  ensuring  potential 
opportunities  for  the  rejection  of  a decision  aiding  system  by  a reluctant 
user,  are  minimized  (see  Chapter  2).  System  developers,  for  example,  take 
great  care  to  ensure  that  the  Initial  operational  version  of  a system  performs 
satisfactorily.  To  lessen  the  impact  of  potential  system  failure,  they  provide 
"manual  backup"  for  the  system  until  It  has  been  accepted  by  the  users.  They 
also  take  considerable  care  to  ensure  that  adequate  support  capabilities— 
e.g.,  maintenance  and  documentation— are  provided  for  the  system. 
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Finally,  and  perhaps  most  importantly,  the  members  of  the  ODAP  should 
work  closely  and  extensively  with  the  operational  community  to  ensure  the 
understanding  of  the  operational  problems,  to  clarify  the  needs,  and  to 
develop  the  appreciation  of  the  procedures  and  style  of  the  operators 
necessary  to  successfully  adapt  the  methodologies  under  study  to  the 
solution  of  the  task  force  commander's  decision  problem  (see  Chapters  2 and 
4).  This  step  is  particularly  important  for  the  ODAP,  which  must  seek  out 
applications  for  its  methodologies  and  which  must  demonstrate  the  capability 
to  deal  effectively  with  the  major  functional  problems  confronting  the 
operational  developer  in  order  to  clearly  demonstrate  the  efficacy  of  the 
methodology.  Problems— such  as  the  determination  of  what  to  display,  how 
to  display  it,  and  how  to  integrate  the  aids  with  the  existing  sources  of 
data— have  not  yet  been  fully  addressed  by  the  ODAP. 

A variety  of  other  issues  are  addressed  in  the  report.  For  example, 
the  integration  of  a decision  aiding  system  into  an  existing  command  and 
control  structure  is  discussed  for  SOTAS  in  Chapter  3.  The  type  of  problems 
encountered— such  as  the  determination  of  appropriate  roles  for  the  system 
and  the  development  of  adequate  measures  for  assessing  the  effectiveness 
of  the  system  within  the  command  and  control  structure— anticipate  problems 
that  are  likely  to  face  the  ODAP.  In  the  discussion  of  SIMTOS  in  Chapter  4, 
a simulation  facility  is  described  that  in  many  respects  parallels  the  vest 
bed  under  development  by  the  ODAP  at  the  University  of  Pennsylvania.  And 
in  the  final  chapter,  two  issues  are  addressed  that  are  important  to  the 
ODAP  but  that  digress  from  the  basic  theme  of  the  report.  In  the  discussion 
of  the  MUDD  system,  attention  is  given  to  the  software  development  problems 
that  frequently  arise  in  the  development  of  decision  aiding  systems.  And 
in  the  discussion  of  AHAB,  an  example  is  described  of  a preliminary  attempt 
to  apply  sophisticated  methodological  techniques  to  a quasi -operational 
system - 
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II.  VESSEL  TRAFFIC  SYSTEM 

The  Vessel  Traffic  System  ( VTS ) , developed  for  the  United  States  Coast 
Guard  by  the  Applied  Physics  Laboratory  of  Johns  Hopkins  University,  moni- 
tors and  advises  vessels  in  San  Francisco  harbor  of  traffic  conditions  in 
the  bay.  VTS  was  conceived,  developed,  and  implemented  as  a computer-aided 
automated  system  to  replace  a manually  operated,  rudimentary  system  that 
lacked  the  capability  to  successfully  handle  projected  traffic  in  the  bay. 
The  concepts  and  associated  hardware  developed  in  VTS  are  now  under 
consideration  for  use  in  other  vessel  traffic  systems  in  U.S.  coastal 
waters. 

In  this  chapter  we  will  stress  the  problems,  solutions,  and  methods 
for  avoiding  problems  that  arose  in  the  development  of  VTS.  We  will  also 
stress  the  characteristics  of  the  system,  for  we  feel  VTS  provides  an 
example  of  a carefully  conceived  system  that  emphasizes  the  needs  and 
desires  of  the  users  of  the  system. 

A.  BACKGROUND 

The  vessel  traffic  control  system  which  existed  in  San  Francisco  Bay 
before  1972  was  generally  recognized  to  be  inadequate  for  safe  and  effec- 
tive control  of  projected  traffic  in  the  bay.  The  system  contained  only  one 
radar,  which  was  located  at  Point  Bonita  near  the  entrance  to  the  bay.  In 
a hut  adjacent  to  the  radar,  a television  camera  focused  on  a PPI  display 
and  transmitted  the  radar  images  to  a control  center  located  some  distance 
away.  Operators  in  the  control  center  maintained  radio  contact  with  vessels 
in  the  bay  and  recorded  the  status  of  the  vessels  by  means  of  a manual  card 
system. 
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With  the  passing  of  the  Ports  and  Waterway  Safety  Act  of  1972  the 
Department  of  Transportation,  through  the  U.S.  Coast  Guard,  was  given 
authority  to  develop,  administer,  and  operate  vessel  traffic  systems  in 
U.S.  port  and  coastal  waters.  Preliminary  study  of  traffic  conditions  in 
San  Francisco  Bay  by  the  Coast  Guard  suggested  the  need  for  a major  new 
vessel  traffic  system.  Moreover,  it  was  concluded  that  a computer-aided 
system  would  meet  the  needs  for  vessel  traffic  control  in  San  Francisco 
Bay  and  would  potentially  be  useful  for  vessel  traffic  control  in  other 
coastal  waters.  As  a consequence,  a program  was  initiated  with  APL  that 
led  to  the  development  of  the  Vessel  Traffic  System. 

B.  BASIC  SYSTEM  DESCRIPTION 

The  VTS  is  an  all-weather,  radar,  communications  complex  which  con- 
sists of:  two  surveillance  radars  with  their  associated  adaptive  video 
tracking  equipment;  traffic  analysis  and  display  computers;  operator  con- 
soles; microwave  radar  relay  links;  ship-to-shore  communications  equipment; 
audio  video  and  digital  recording  equipment;  and  operating  personnel. 

The  VTS  covers  the  area  shown  in  Figure  II-l.  In  the  Radar  region, 
coverage  on  vessels  in  the  bay  is  maintained  by  surveillance  radars  at 
Point  Bonita  and  on  Yerba  Buena  Island.  In  the  Vessel  Movement  Reports  (VMR) 
region,  which  is  not  covered  by  radar,  contact  with  the  Vessel  Traffic  Center, 
located  on  Yerba  Buena  Island,  is  maintained  exclusively  by  radio. 

The  VTS  has  both  a manual  and  an  automatic  operating  mode.  Due  to  the 
absence  of  radar  coverage  in  the  VMR  region,  the  operating  procedures  for 
each  mode  differ  in  the  Radar  and  the  VMR  regions. 

For  the  Manual  Operating  Mode  in  the  VMR  reron,  the  procedures  closely 
parallel  those  of  the  original  vessel  control  system.  On  entering  the 
region,  a vessel  reports  its  identity,  position,  destination,  and  desired 
route  to  the  control  center.  An  operator  in  the  center  records  the  reports 
on  a Vessel  Data  Card  and  plots  positions  of  the  vessels  on  a large  wall 
map.  A separate  card  is  maintained  for  each  vessel,  so  that  3 ^'■ord  of  its 
movements  is  available  for  review. 
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For  the  Manual  Operation  Mode  in  the  Radar  region,  the  procedures  dif- 
fer from  those  in  the  VMR  region  in  that  the  operator  views  the  vessel 
traffic  on  a PPI  (radar)  display.  As  in  the  VMR  region,  the  operator 
records  the  data  for  the  vessel  on  Vessel  Data  Cards.  He  then  traces  the 
vessels  either  on  the  wall  map  or  directly  on  the  :,PI  screen. 

For  the  Automatic  Operating  Mode  in  the  VMR  region,  the  procedures 
differ  only  slightly  from  those  in  the  Manual  Operatinq  Mode.  An  operator 
may  enter  data  into  the  VTS  computer  via  a keyboard  at  the  VTS  display  con- 
sole—to  be  described  below— and  subsequently  retrieve  the  data  to  display 
the  list  of  VMR  vessels,  including  their  names,  positions,  time  of  last 
report,  and  expected  position  and  time  of  next  report.  If  the  next  report 
is  not  received  by  the  expected  time,  an  automatic  alert  (alarm)  is  sounded 
by  the  system. 

For  the  Automatic  Operating  Mode  in  the  Radar  region,  the  procedures 
make  use  of  the  full  capabilities  of  the  automated  system.  This  system  is 
composed  of  the  Automatic  Detection  and  Tracking  (ADT)  subsystem,  one  of 
which  is  associated  with  each  radar,  and  the  Traffic  Analysis  and  Display 
(TAD)  subsystem. 

The  ADT  subsystem  relieves  the  operator  of  the  need  to  detect  and  track 
vessel  traffic.  By  using  adaptive  detection  thresholds  keyed  to  the  average 
clutter  return  in  each  area,  the  subsystem  is  able  to  automatically  detect, 
classify,  and  track  vessels  in  the  bay.  Tracks  maintained  by  the  system 
are  classified  as  new,  tentative  or  firm.  For  the  firm  tracks,  estimates 
are  made  of  a vessel's  size,  speed,  and  course.  Up  to  253  total  tracks  may 
be  maintained  per  ADT,  with  an  omission  rule  in  the  event  of  overload,  which 
drops  new  and  tentative  tracks  before  firm  tracks,  and  tracks  for  small 
vessels  before  tracks  for  large  vessels. 

The  TAD  subsystem  accepts  firm  tracks  from  the  two  ADT  subsystems, 
processes  them,  and  then  displays  them  for  the  operator.  The  display  con- 
sole for  the  subsystem  is  shown  in  Figure  1 1 -2 . The  Working  Display  is  in 
the  center  of  the  figure  with  two  satellite  displays  at  the  top.  The  key- 
board and  special  feature  controls— including  the  track  ball  to  the  far 
right-are  shown  in  the  lower  half  of  the  figure. 
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On  the  Working  Display,  the  operator  may  display  either  the  map--as  in 
Figure  II-2— or  the  contents  of  the  satellite  displays,  which  provide  infor- 
mation on  the  name,  course,  and  destination  of  the  vessels  in  the  bay. 

The  scale  of  the  map  may  be  changed  and  its  center  displaced  to  allow  the 
operator  to  examine  a particular  area  in  greater  detail.  Associated  with 
thf*  map  are  windows  that  provide  the  operator  with  supplementary  information 
on  the  status  of  vessel  traffic  in  the  bay.  In  the  figure,  for  example, 
the  system  has  generated  a collision  alert  for  two  vessels  whose  current 
range  is  2,000  yards  and  closing. 


The  method  used  to  generate  the  map  for  the  Working  Display  is  one 
of  the  most  interesting  features  of  VTS.  The  system  employs  a synthetic 
display.  Rather  than  displaying  the  video  returns  from  the  radars  directly— 
e.g.,  in  the  form  of  a PPI  display— only  the  processed,  firm  tracks  are  shown 
on  the  map.  These  tracks  are  stored  in  the  TAD  computer  and  are  read  out 
periodically  to  generate  the  display.  Thus,  neither  clutter,  undetected 
vessels,  nor  new  or  tentative  tracks  appear  on  the  map 


In  addition  to  the  firm  tracks,  traffic  lanes— whose  boundaries  are 
indicated  by  dotted  lines— vessels,  buoys,  and  other  identifiers  are  also 
displayed  on  the  map.  The  complete  set  is  listed  in  Table  II-l.  Special 
symbols  are  provided  for  buoys,  buoys  that  are  adrift,  and  lost  contacts. 
Identified  vessel s— those  with  which  radar  contact  has  been  established 
and  which  have  been  correlated  with  a firm  track— and  unidentified  vessels 
are  distinguished.  The  identified  vessels  have  their  name,  course,  and 
destination  displayed  on  the  satellite  displays.  The  leader  line,  which 
can  also  be  seen  in  Figure  1 1-2 , is  used  to  display  the  heading  and  future 
position  of  a vessel.  The  remaining  symbols  on  the  display— cursor,  hook, 
and  set— are  used  by  the  operator  to  request  specific  operations.  These 
will  be  described  later. 
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TABLE  II-l 
OISPLAY  SYMBOLS 


SYMBOL 

NAME 

SYMBOL 

NAME 

automat;c  SYMBOLS  (ALL  DISPLAYS) 

Lane  Boundary 

□ 

Identified  Active  Vessel 

• 

Buoy 

Unidentified  Active  Vessel 

tf 

Drifted  Buoy 

r— ✓05 

[E^ 

Vessel  Number  (or  Tag)a 

X 

Out-of-Track  Buoy 

S' 

Lost  Identified  Contact 

OPERATOR  CONTROLLABLE  SYMBOLS  (WORKING  DISPLAY) 


Set 

Leader  Line 

"The  operator  can  choose  to  display  the  number  or  not  to  display  it. 


t 

Cursor 

0 

Hook 

C.  AUTOMATIC  SYSTEM  FEATURES 


Most  of  the  automatic  features  of  the  VTS  employ  the  Automatic  Detec- 
tion and  Tracking  (ADT)  subsystem.  As  previously  described,  this  subsystem 
permits  vessels  to  be  detected  through  the  use  of  an  adaptive  threshold 
tha"  is  keyed  to  the  average  clutter  return.  The  automatic  features  available 
to  the  operator  at  the  main  console  which  use  the  ADT  subsystem  may  be 
classified  into  those  that  are  available  by  operator  request  and  those 
that  are  provided  by  automatic  alerts.  These  include: 


By  operator  request 


Speed  and  course  data.  For  identified  vehicles,  the  operator 
may  display  a vessel's  name,  position,  heading,  origin, 
destination,  size,  and  ancillary  identification  data. 


Future  position.  With  the  leader  lines,  linear  course  pro- 
jections can  be  made  for  1-,  2-,  or  6-minute  intervals. 


ll 


m 


Relative  position.  The  relative  position  capability  permits 
the  operator  to  select  a point--usually  a vessel— using  the 
track  ball  and  then  to  select  a second  point— also  usually 
a vessel --and  to  obtain  the  bearing  and  range  between  the  two 
points.  The  values  of  the  range  and  bearing  are  printed  in  a 
Working  Display  window  and  a vector  between  the  two  points 
is  displayed  on  the  map. 

Closest  point  of  approach  (CPA).  The  CPA  capability  is  similar 
to  the  relative  position  calculation  except  that  the  bearing 
range  determination  is  made  at  the  point  of  closest  approach 
of  two  vessels  or  of  a vessel  and  a fixed  point.  The  time  to 
CPA  and  the  range  at  CPA  are  displayed  in  a window  of  the 
Working  Display. 

• By  automatic  alert 

Potential  collisions.  A collision  alert  is  generated  if  a 
vessel  closes  to  within  1,000  feet  of  another  vessel 
within  the  next  4 minutes.  The  warning  is  both  audio  and 
visual.  The  "collision  alert"  in  the  Working  Display  of 
Figure  11-1  corresponds  to  the  visual  portion  of  the  warning. 
Upon  notification  of  the  alert,  the  operator  may  request  the 
CPA  for  the  two  vessels.  The  position  and  orientation  of 
the  vessels  are  then  displayed  on  the  map.  If  the  situation 
persists,  the  developing  situation  may  be  recorded  for  future 
reference. 

Drifting  buoys.  A buoy  that  drifts  off  station  has  the  nor- 
mal dot— see  Table  II-l — replaced  by  a dot  with  a diamond  on 
top.  No  audio  warning  is  supplied. 

Loss  of  track.  When  track  is  lost  on  an  identified  vessel, 
a blinking  "X"  appears  at  the  last  known  location  of  the  ves- 
sel with  a leader  line  showing  the  speed  and  course  at  the 
time  of  loss.  A blinking  "R"  also  appears  on  the  Vessel  Data 
Display  opposite  the  name  of  the  vessel.  Loss  of  track  on  a 
drifting  buoy  also  causes  an  "X"  to  appear  at  the  last  known 
contact,  but  the  symbol  does  not  blink  nor  is  a leader  line 
attached. 


Other  automatic  features  are  included  in  the  system.  Of  most  interest 
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to  the  ODAP  is  the  treatment  of  multiple  alerts.  The  procedure  used  in  the 
system  for  handling  them  is  to  first  assign  a priority  value  to  each  alert. 
For  example,  if  alerts  are  generated  for  two  potential  collisions,  the  one 
with  the  shorter  time  to  collision  is  assigned  the  highest  priority.  The 
alert  with  the  highest  priority  is  then  displayed  in  one  of  the  windows 
of  the  Working  Display  called  the  Alert  Message  Section.  If  the  alert  is 
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a potential  collision,  the  window  contains  the  designators  of  the  two  ves- 
sels involved  and  the  time  to  collision.  Also  displayed  in  the  window  is  a 
second  message  giving  the  total  number  of  alerts  in  the  system.  When  the  first 
alert  is  processed--for  example,  by  requesting  the  positions  of  the  vessels  at 
CPA--the  alert  with  the  se:ond  highest  priority  automatically  appears  in  the 
window.  The  procedure  is  then  repeated  for  additional  alerts. 


D.  DISCUSSION 

1 . System  Development:  Approach 


i 
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i 
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The  approach  is  probably  the  most  important  element  in  the  devel-  | 
opment  of  a system.  The  key  to  the  approach  is  the  clear,  unambiguous,  ; 1 
and  mutually  agreed  upon  definition  of  what  the  system  is  supposed  to  do,  I I 


i.e.,  the  functional  requirements  for  the  system.  The  developers  of  VTS 
strongly  support  this  view  and,  in  fact,  recommend  a four  step  approach  to 
system  development: 

• The  definition  of  the  functional  requirements  for  the  system. 
This  step  requires  the  determination  of  precisely  what  the 
system  is  required  to  do.  It  provides  the  developer  with  a 
well -determined  set  of  design  objectives  and  minimizes  the 
likelihood  of  the  need  for  later  revisions  in  the  system  due 
to  a lack  of  common  understanding  of  the  requirements  of  the 
system. 
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• The  preparation  of  the  conceptual  design.  This  is  the  quali- 
tative design  of  the  system.  For  example,  in  VTS  during  the 
conceptual  design  phase,  it  was  decided  to  use  bright  inter- 
active displays. 

• The  determination  of  the  hardware  and  software  specifications. 
In  this  step,  for  example,  the  specifications  necessary  to 
define  the  ADT  and  TAD  systems  are  established. 

• The  selection  or  design  of  the  necessary  hardware  and  soft- 
ware. This  includes  the  development  of  the  mathematical 
algorithms  necessary  for  the  system.  It  is  the  area  of  pri- 
mary focus  in  the  ODAP. 

The  adoption  of  this  approach  alleviates  many  of  the  common  prob- 
lems in  system  development  that  stem  from  a lack  of  understanding  of  the 
functional  requirements  for  the  system  or  from  a failure  to  systematically 
translate  the  requirements  into  the  detailed  characteristics  of  the  system. 
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2.  System  Development:  Communication 

The  need  for  close  and  protracted  interaction  between  the  devel- 
opers of  a system  and  the  eventual  users  was  strongly  emphasized  by  the 
developers  of  VTS.1  In  developing  VTS,  they  literally  spent  weeks  in 
San  Francisco  working  with  the  operators  to  develop  both  the  functional 
requirements  and  the  conceptual  design  of  the  system.  They  described  this 
phase  as  the  most  difficult  and  important  part  of  the  development.  Detailed 
discussions  with  the  operators  indicated  that  they  did  not  initially  have 
a clear  understanding  of  what  was  needed  in  the  new  system,  nor  were  they 
able  to  evaluate  effectively  a particular  design  before  they  saw  it  in  oper- 
ation. Thus,  the  developers  had  to  work  very  closely  with  the  operators  to 
develop  their  own  understanding  of  the  existing  system  and  the  requirements 
for  the  new  system.  Throughout  the  subsequent  development  of  the  system, 
the  developers  maintained  very  close  contact  with  the  operators  to  help  keep 
the  program  on  target  and  to  give  the  operators  the  opportunity  to  keep 
abreast  of  the  program.  The  system  developers  said  that  without  this  inter- 
action the  system  would  probably  not  have  been  successful. 

One  persistent  problem  that  arose  repeatedly  during  the  discus- 
sions between  the  system  developers  and  the  operators  was  their  lack  of 
common  language.  In  many  instances,  the  developers  and  the  operators  simply 
did  not  mean  the  same  thing  by  the  same  words.  And  the  situation  v/as  fur- 
ther complicated  in  instances  where  a subject  was  not  thoroughly  discussed 
because  "everyone  knows  what  needs  to  be  done  there."  It  became  apparent 
that  where  there  is  a difference  in  background  between  developers  and  users— 
as  there  nearly  always  is— all  aspects  of  a problem  must  be  discussed  in 
the  most  concrete  and  detailed  way  in  order  to  insure  a common  understanding. 
The  designers  of  VTS  recognized  this  and  their  persistent  and  protracted 
discussions  with  the  operating  personnel  appear  to  have  contributed  sub- 
stantially to  the  successful  development  of  the  VTS  system. 


xThe  developers  of  VTS  also  emphasized  that  the  Coast  Guard  was  very  much 
aware  of  the  need  for  a close  working  relationship  between  the  two  groups 
and  cooperated  fully  with  them. 


3.  System  Development:  Information  Filtering 

A major  problem  that  arises  in  almost  all  automated  decision 
systems  is  the  generation  of  more  data  than  the  decisi . nmaker  can  handle 
effectively.  In  these  systems  some  method  must  be  developed  to  reduce  the 
data  load  to  an  amount  and  form  with  which  the  operator  can  effectively 
work.  In  VTS  this  is  accomplished  by  means  of  the  synthetic  display. 

The  synthetic  display  permits  the  operator  to  view  only  the  firm 
tracks.  Clutter  and  other  imagery  that  appear  on  a PPI  is  suppressed  on  the 
synthetic  display.  The  operator,  therefore,  has  to  deal  only  with  data  that 
is  relevant  to  his  decisionmaking  process. 


Although  this  procedure  considerably  simplified  the  analysis  of 
data,  problems  with  the  procedure  arose  as  a consequence  of:  (1)  an  opera- 
tor concern  that  buried  in  the  raw  data  is  another  vessel  for  which  a firm 
track  had  not  yet  been  established  and  which,  therefore,  does  not  appear  on 
the  synthetic  display,  and  (2)  a psychological  need  for  the  operator  to  view 
all  data  produced  by  the  system.  Experimental  verification  that  the  ADT 
subsystem  detected  vessels  far  more  effectively  than  the  unaided  human 
observer  did  not  alleviate  the  problem. 

This  situation,  in  which  the  raw  data  is  not  available  to  the 
operator  leads  to  less  than  full  satisfaction  with  a system,  is  common  to 
many  of  the  systems  we  have  examined.  It  strongly  suggests  that  a useful 
principle  in  system  design  is  to  preserve  and  provide  a capability  within 
a system  that  permits  the  operator  to  observe  the  raw  data  if  he  so  desires. 
For  VTS,  the  situation  was  easily  corrected  by  placing  two  PPI  displays  to 
each  side  of  the  Working  Display.  An  operator  then  had  immediate  access 
to  the  raw  data. 

In  sum,  a major  problem  in  developing  computer-aided  decision 
systems  and  especially  in  developing  any  form  of  fully  automated  decision 
system  is  in  condensing,  filtering,  evaluating,  and  presenting  the  large 
quantities  of  data  that  are  generated.  The  problem  is  particularly  acute 
in  a hostile  environment  in  which  it  is  the  unusual  items  of  data  or  an 
unanticipated  pattern  in  the  data  that  is  important.  Researchers  have,  in 
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general,  tended  to  shy  away  from  the  problem  because  of  the  difficulty  of 
the  problem,  because  other  relatively  more  easily  solved  problems  are  also 
pressing,  and  because  solutions  tend  to  be  tailored  to  specific  applica- 
tions. In  our  judgment,  more  research  in  this  area  is  certainly  warranted 

and  the  payoff  resulting  from  the  research  is  likely  to  be  considerable. 

4.  System  Acceptability:  Appearance 

The  physical  appearance  of  a system  often  plays  a critical,  if 
not  decisive,  role  in  whether  a system  is  accepted  by  the  users.  Neverthe- 
less, we  have  found  that,  this  seemingly  self-evident  principle  is  repeatedly 
violated  by  system  developers.  The  tendency  to  overlook  the  importance  of 
physical  appearance  is  particularly  pronounced  among  those  with  an  academic 
orientation,  who  have  a tendency  to  be  preoccupied  with  the  development  of 
mathematical  algorithms,  with  procedures  for  retrieving  information,  and 
with  clever  ways  for  performing  their  particular  calculations.  They  tend 
to  forget  the  potential  users  of  the  system,  whose  acceptance  is  critical 
to  its  success,  and  who  rarely  understand  or  care  about  the  detailed  struc- 
ture of  the  system  itself. 

The  developers  of  VTS  fully  appreciated  the  importance  of  the 
appearance  of  a system  and,  in  fact,  expended  considerable  resources  in 
modifying  their  system  to  make  it  more  attractive.  As  originally  designed, 
the  VTS  system  used  storage  tube  displays.  With  this  type  of  display  an 
image— such  as  the  map  appearing  on  the  Working  Display— can  be  written  on 
a storage  surface  within  the  display  tube.  Therefore,  neither  the  map  data 
nor  the  associated  software  required  for  repeatedly  "refreshing"  the  display, 
needed  to  be  stored  in  the  computer. 

After  work  with  the  system  was  partially  completed,  the  developers 
found  that  the  display  "did  not  look  very  good"  and  tended  to  go  out  of 
alignment,  thereby  requiring  an  unusual  amount  of  maintenance.  A decision 
was  then  made  to  use  computer-refreshed  displays,  in  which  the  map  is  con- 
tinually refreshed  in  a manner  similar  to  that  used  in  conventional  tele- 
vision receivers.  This  change  required  extensive  reprogramming  of  the 
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software  for  the  system  and  dedication  of  valuable  storage  to  preserve  the 
map  data,  but  the  developers  of  VTS  felt  appearance  to  be  of  such  importance 
that  the  change  was  justified. 

5.  System  Acceptability:  Ease  of  Learning  and  Operation 


In  the  development  of  many  new  systems,  the  training  of  operators 
is  discussed  seriously  only  wnen  the  design  of  the  system  is  nearly  com- 
pleted. Frequently,  at  this  stage  extensive  training  programs  for  the 
operators  are  proposed  and,  occasionally,  the  point  is  reached  where  a 
Ph.D.,  skilled  in  the  particular  discipline,  is  recommended  to  head  the 
user  team.  All  sight  is  lost  of  the  general  principle  that  successful 
systems  tend  to  be  easy  to  learn  and  easy  to  operate.  This  principle  can 
often  be  easily  met,  or  at  least  the  burden  placed  on  the  operators  greatly 
alleviated,  simply  by  giving  greater  attention  to  the  requirements  placed 
on  the  operators  during  the  initial  design  phase  of  the  system. 

The  development  of  systems  that  are  easy  to  learn  and  operate  can 
benefit  a developer  in  many  ways.  Many  visitors  to  APL  observed  the  displays 
and  were  favorably  impressed  by  them.  As  a consequence,  APL  had  the 
opportunity  to  consider  the  use  of  the  displays  in  other  programs. 

In  developing  systems  for  other  programs  and  other  customers,  an 
important  point  that  should  be  carefully  considered  in  planning  a new  system 
is  that  the  "personality"  of  the  customer  for  whom  work  is  done  can  substan- 
tially influence  how  the  work  must  be  performed.  The  Coast  Guard,  for 
example,  was  a new  customer  to  R&D.  As  a consequence,  they  were  not  locked 
into  standardized  procedures  and  technologies  and  were  especially  open  to 
new  and  innovative  ideas.  APL  was,  thus,  able  to  exercise  great  freedom  in 
both  the  design  and  selection  of  hardware  for  the  system.  By  contrast,  the 
Mavy  is  very  experienced  in  R&D.  Consequently,  a designer  developing  a new 
system  for  the  Navy  would  find  it  necessary  to  accommodate  what  was  being 
done  by  others,  to  obtain  multiple  approvals  for  each  new  feature  of  the 
system,  and  to  use  approved  equipment— e.g. , the  UYK  computer.  A designer 
would  thus  need  to  develop  a system  for  the  Navy  within  a much  tighter  set 
of  constraints  than  APL  found  necessary  for  the  Coast  Guard. 
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6.  Acceptance  of  Automation:  Key  Events 

There  is  often  a strong  reluctance  among  users  to  accept  a new 
computer-aided  decision  system.  To  overcome  this  reluctance  and  to  check 
out  the  system,  there  is  frequently  a period  in  which  the  old  manual  and 
the  new  automated  system  are  used  concurrently.  The  eventual  acceptance 
or  rejection  of  the  automated  system  then  frequently  depends  on  the  outcome 
of  certain  key  events  in  which  one  or  the  other  of  the  systems  fail.  A 
simple  example  of  this  type,  which  had  a favorable  outcome  for  the  automatic 
system,  occurred  in  VTS.  An  operator  working  in  the  automatic  mode  con- 
cluded a particular  vessel  had  run  aground.  (The  velocity  readout  was 
zero.)  The  operator  of  the  manual  system  strongly  disagreed.  Shortly 
thereafter,  the  captain  of  the  vessel  radioed  and  confirmed  he  had  indeed 
run  aground.  Henceforth,  the  automatic  mode  was  looked  upon  with  considerably 
more  favor. 


Just  as  such  favorable  events  contribute  to  the  acceptance  of  a 
system,  unfavorable  events  can  contribute  to  its  rejection— often  much  more 
dramatically.  One  case,  involving  only  a very  limited  amount  of  automation, 
occurred  in  introducing  digital  depth  gauges  to  submarines.  The  digital 
gauge  was  intended  to  supplement  the  mechanical  analog  gauge  that  had  been 
in  use  for  many  years.  It  was  introduced  on  a display  along  with  two  analog 
gauges  that  provided  the  manual  backup.  As  it  turned  out,  the  digital  gauge 
on  one  submarine  failed.  For  some  reason  the  operators  did  not  observe  the 
backup  gauge  and  the  ship  was  endangered  before  the  operators  became  aware 
of  the  situation  and  were  able  to  take  corrective  action. 


As  a consequence,  a veritable  outcry  was  heard  within  the  Navy 
that  culminated  in  an  order  to  remove  the  gauges  from  the  submarines.  This 
occurred  notwithstanding  the  fact  that  analog  gauges  also  fail  and  the 
cause  of  the  failure  of  the  digital  gauge  was  readily  correctable. 

A second  example  is  provided  by  the  Navy's  Conolcgue  system. 
Conologue  was  designed  to  aid  an  inexperienced  helmsman.  In  order  to  remain 
on  a prescribed  course  and  at  prescribed  depth,  the  helmsman  need  only 
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follow  a highway  depicted  on  a CRT.  If  the  submarine  drift.;  to  the  right 
of  its  prescribed  course,  the  highway  moves  to  the  left  on  the  CRT,  and 
the  helmsman  might  adjust  his  course  to  the  left,  to  move  the  highway  back 
to  the  center  of  the  display.  If  the  submarine  drifts  above  its  prescribed 
depth,  the  highway  moves  to  the  bottom  of  the  display  and  the  helmsman  must 
then  adjust  his  heading  downward  to  move  the  highway  back  to  ’;he  center  of 
the  display. 

In  tests  at  sea  the  system  proved  to  be  very  useful,  especially 
in  a rough  sea  where  it  is  difficult  to  maintain  a prescribed  depth.  Based 
on  its  successful  performance  in  these  tests,  operational  implementation  of 
the  Conologue  system  was  approved. 


In  operation  the  system  ran  into  extensive  problems.  Maintenance 
time  was  excessive.  Documentation  of  the  technical  characteristics  of  the 
system  was  so  poor  and  maintenance  training  so  incomplete  that  correction 
of  one  problem  frequently  created  another.  Dissatisfaction  with  the  system 
soon  grew  rampant  and  eventually  resulted  in  an  order  to  remove  Conologue 
from  the  fleet. 

In  both  of  these  examples  there  were  no  fundamental  problems  with 
the  decision  aid.  In  the  case  of  the  digital  depth  gauge  the  problem  was 
probably  unavoidable;  whereas,  with  Conologte,  greater  attention  to  system 
support  function  might  have  avoided  the  problems  that  w<.-re  encountered. 

The  essential  point,  however,  is  that  in  a computer-aided  decision  system 
whe^e  there  is  inevitably  a reluctance  by  users  to  accept  the  system,  the 
greatest  care  must  be  exerted  to  avoid  system  failure  if  the  system  is  to 
be  accepted.  Such  commonly  heard  arguments  as:  "We  are  only  testing  out 
a new  principle;  we  do  not  have  to  worry  about  operational  details,"  and 
"Operational  problems  are  someone  else's  headache,  our  inte  est  is  in  the 
mathematical  development"  are  wholly  inconsistent  with  the  attitude  and 
approach  that  has  been  adopted  in  the  development  of  successful  systems. 
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7.  System  Acceptability:  Documentation 


The  contribution  of  documentation  toward  gaining  the  acceptance 
of  a system  has  been  noted  in  the  discussion  of  the  Navy's  Conologue  system. 
The  developers  of  VTS  paid  considerable  attention  to  the  preparation  of 
useful  and  easily  assimilable  documentation.  Figure  I 1-2 , which  we  dis- 
cussed earlier  in  the  chapter,  was  taken  from  a document  on  console  opera- 
tion that  provides  a reference  source  for  each  of  the  activities  (service 
procedures)  that  the  operator  must  perform.  The  alphanumeric  designators 
appearing  in  the  figure  are  identified  in  Table  I 1-2,  which  followed 
Figure  I 1-2  in  the  original  document.  Note  that  each  operational  step 
is  clearly  defined,  including  a statement  of  its  purpose  and  the  results 
of  completing  the  step.  References,  such  as  "hook,  "XEQ,"  and  "Real 
Time  Data  Service,"  are  carefully  defined  earlier  in  the  document. 

The  clarity  of  this  particular  example  is  representative  of  the 
quality  of  the  entire  set  of  documents  and  reflects  the  care  and  attention 
that  was  given  to  its  preparation.  We  feel  that  it  contributed  significantly 
to  the  acceptance  of  the  system. 


E.  SUMMARY 

We  end  the  chapter  with  a quote  from  Mr.  Andreas  C.  Schultheis,  Program 
Manager  of  the  VTS  system  development  at  APL: 

3 

I believe  that  the  C system  design  is  predicated  on  a 
tradeoff  between  available  state-of-the-art  technology 
and  philosophy,  all  based  on  good  common  sense  and  under- 
standing of  the  mission's  operational  requirements.  In 
my  work  I have  not  found  any  major  design  formulas  and  I 
really  do  not  think  they  exist.  I found  you  have  to  learn 
to  put  yourself  in  the  operator's  seat  and  imagine  how  you 
would  want  the  operation  to  run— what  displays,  data,  and 
information  are  needed  to  perform  the  mission.  To  build 
a successful  system,  it  then  takes  a unique  blend  of 
technical  knowledge  of  what  can  be  done,  a very  good 
appreciation  and  understanding  of  operational  require- 
ments, and  detailed  knowledge  of  mission  requirements. 
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F.  SOURCES 

Mr.  Andreas  C.  Schultheis  was  Program  Manager  for  the  Vessel  Traffic 
System  (VTS)  at  the  Applied  Physics  Laboratory  of  the  Johns  Hopkins 
University.  Documentation  of  the  Vessel  Traffic  System,  entitled  San 
Francisco  Vessel  Traffic  System  Operations  and  Maintenance  Manual,  Vols.  I, 
II,  III,  December  1973,  is  available  from  the  National  Technical  Information 
Service,  Springfield,  Virginia  22151. 
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III.  THE  STANDOFF  TARGET  ACQUISITION  SYSTEM  (SOTAS) 


The  Standoff  Target  Acquisition  System  (SOTAS),  under  development  by 
the  U.S.  Army  Electronics  Command,  is  designed  to  assist  a military  commander 
in  making  decisions  concerning  the  deployment  and  utilization  of  his  forces. 
SOTAS  gathers  and  processes  useful  and  timely  information  on  target  movement 
and  location  in  the  region  beyond  the  ground  line-of-sight,  and  then  trans- 
mits this  information  to  the  division. 


SOTAS  differs  from  other  computerized  decision  aids  described  in  this 
report  in  that  it  is  an  independently  developed  system  that  must  be  inte- 
grated into  an  existing  command  and  control  system.  As  such,  it  provides 


an  excellent  case  study  for  the  ODAP.  Most  operational  decision  aids  now 


actively  in  use  consist  merely  of  the  automation  of  existing  well -structured 
procedures  and,  thus,  do  not  face  the  integration  problem. 


A.  SYSTEM  DESCRIPTION 


U.S.  military  forces  are  not  currently  equipped  with  effective  means 
for  detection,  location  and  tracking  of  enemy  ground  targets  beyond  ground 
line-of-sight.  SOTAS  provides  this  capability  through  the  use  of  an  airborne 
radar  that  relays  imagery  in  real-time  to  ground  display  facilities,  which 
process  the  data  and  relay  it  to  a command  center. 

The  proposed  configuration  of  the  system  is  shown  in  Figure  III-l.  It 
consists  of  a helicopter,  equipped  with  an  MTI  radar;  a master  ground  station 
(located  in  the  display  trailer)  equipped  with  CRT  displays,  a computer  and 
magnetic  tape  memories;  a ground  radar  tracker;  and  one  or  more  remote 
terminals  having  similar  but  reduced  capabilities  to  those  of  the  master 
ground  station.  In  operation,  the  radar  returns  are  processed  to  detect 
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moving  targets,  converted  to  digital  form,  and  transmitted  to  the  ground 
station  for  display  and  recording.  The  ground  computer  and  CRTs  provide 
either  real-time  display  or  time-compressed  playback  of  imagery.  The  radar 
tracker  tracks  the  helicopter,  so  that  target  coordinates  measured  in  the 
helicopter  system  can  be  accurately  expressed  in  a ground-based  system.  The 
remote  terminals  permit  direct  access  to  the  data  from  the  helicopter  by 
elements  having  a need  for  near  real-time  information. 

B.  SYSTEM  INTEGRATION 

The  Vessel  Traffic  System  (VTS)  is  a complete,  stand-alone  system  that 
totally  replaced  the  existing  command  and  control  system  for  monitoring  and 
advising  vessel  traffic  in  San  Francisco  Bay.  SOTAS,  on  the  other  hand, 
supplements  the  existing  Army  command  and  control  system  by  providing  data 
on  targets  lying  beyond  the  line-of-sight  of  the  ground  forces.  SOTAS  data 
is  combined  with  data  from  other  sources  to  provide  the  information  needed 
by  the  tactical  commanders  in  their  decisionmaking  roles.  Therefore,  for 
SOTAS,  consideration  must  be  given  to  a system  integration  which  is  not 
faced  by  VTS. 

The  nature  of  the  integration  problems  as  they  relate  to  automated 
decision  aids  becomes  apparent  when  the  flow  of  information  through  the 
SOTAS  system  and  into  the  command  and  control  system  is  examined.  This 
flow  begins  with  the  collection  of  large  quantities  of  raw  data  by  the 
helicopter  and  transmission  of  this  data  to  the  ground  station.  At  the 
ground  station  an  operator  examines  the  data  on  a conventional  CRT  display 
and  identifies  those  activities  that  appear  to  warrant  further  evaluation. 

In  the  course  of  executing  this  procedure,  the  operator  must  address  such 
objective  questions  as  "Which  data  are  clutter?"  and  "Which  data  represent 
the  movement  of  a tank  column  down  a road?"  and  such  more  judgmental  ques- 
tions as,  "Which  data,  when  perceived  as  a pattern,  indicate  the  presence 
of  unanticipated  activity  in  the  battlefield?" 


After  the  operator  has  processed  the  data  in  the  master  ground  station, 
it  is  forwarded  to  an  officer-in-charge,  who,  after  reviewing  and  further 
interpreting  the  data  prepares  a message  for  transmission  to  the  Division 
Tactical  Operations  Center  (DTOC),  which  is  the  connecting  link  between 
SOTAS  and  the  command  and  control  system.  The  form  in  which  information 
would  typically  be  conveyed  is  illustrated  by  the  following  message: 

An  enemy  helibome  operation  has  just  begun  at  0182  proceeding  from 

Heidelberg  in  a North-Easterly  direction  at  45  knots.  There  appears 

to  be  10  vehicles  in  the  formation. 

Upon  reception  of  the  message  at  the  DTOC,  it  is  integrated  with  data 
from  other  sources  and  then  used  in  planning,  in  making  real-time  force  and 
combat  unit  assignments,  and  in  other  decisionmaking  activities. 

The  examination  of  information  flow  in  SOTAS  and  between  SOTAS  and  the 
DTOC  illustrates  a number  of  important  points.  The  first  is  the  degree  to 
which  the  command  and  control  system  determines  the  requirements  for  and  the 
configuration  of  the  SOTAS  system,  as  well  as  the  requirements  for  individual 
decision  aids.  Without  the  explicit  recognition  of  and  accounting  for  this 
relationship,  it  would  be  extremely  difficult  to  develop  an  effective  and, 
indeed,  even  a workable  system. 

The  second  point  concerns  the  complexity  of  the  interface  between  SOTAS 
and  the  command  and  control  system.  As  a consequence  of  this  complexity,  a 
validation  of  the  effectiveness  of  the  system  requires  a demonstration  that 
the  system  could  be  interfaced  with  existing  or  proposed  command  and  control 
systems.  This  is  a point  especially  relevant  to  the  ODAP,  which  must  not 
only  demonstrate  that  useful  aids  can  be  developed  using  the  methodologies 
under  study,  but  that  they  can  be  incorporated  into  the  command  and  control 
systems.  The  work  in  the  ODAP  for  the  Interim  Tactical  Flag  Command  Center 
(ITFCC)  represents  a step  in  this  direction. 

The  final  point  concerns  the  implications  of  the  information  processing 
requirements  for  automation.  The  activities  which  led  to  the  preparation  of 
the  message  on  the  heliborne  operations  involved  considerable  in/erpretation, 
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evaluation  and  judgment— activities  which  are  generally  felt  to  be  better 
performed  by  human  beings  than  by  computers.  Although  the  computer  could 
be  helpful  in  many  of  the  intermediate  calculations,  the  automation  of  the 


full  process  appears  to  be  beyond  the  present  data  capabilities  of  computers 
and  software  designers.1 


C.  COMMAND  AND  CONTROL  STRUCTURE 


In  the  preceding  section,  the  discussion  stressed  the  structure  of  SOTAS 
and  its  interface  with  the  command  and  control  system.  In  the  discussion, 
the  command  and  control  system  was  represented  only  through  the  Division 
Tactical  Operations  Center  (DTOC),  which  integrated  the  data  from  SOTAS 
with  data  from  other  sources  for  use  in  planning,  in  making  real-time 
artillery  assignments  and  in  other  decisionmaking  activities.  In  this 
section,  we  will  describe  the  interface  of  SOTAS  and  command  and  control 
system  in  greater  detail. 


1. 


Organizational  Structure 

A major  consideration  in  developing  an  operational  system  is  the 
integration  of  the  system  into  the  existing  organizational  structure.  Tra- 
ditional organizational  structures  were  not  developed  for  modern  computerized 


In  general,  the  investigation  uncovered  very  little  interest  in  fully 
automated  systems.  Commanders,  in  particular,  expressed  an  extreme 
reluctance  to  permit  computers  to  make  decisions  that  affect  the  survival 
of  their  own  forces.  In  such  situations,  they  felt  it  was  imperative  to 
have  a man-in-the-loop.  The  notable  exceptions  where  full  automation  has 
been  implemented  have  occurred  in  situations  where  a man  cannot  react  quickly 
enough  to  make  and  implement  the  necessary  decisions.  For  example,  reactors 
on  nuclear  submarines  are  automatically  shut  down  in  the  event  of  a mal- 
function; naval  steam  boilers  have  their  water  levels  regulated  by  a simple 
control  device,  because  man  is  unable  to  react  quickly  enough  to  regulate 
them  in  a combat  environment.  In  the  latter  case,  however,  the  commander 
generally  still  assigns  a man  to  watch  the  water  level  for  failure  of  the 
device  endangers  the  safety  of  the  ship,  and  the  commander  does  not  have 
sufficient  confidence  in  the  device  to  leave  it  unattended. 
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warfare  and  may,  therefore,  not  be  ideally  suited  to  it.  As  a consequence, 
a decision  aiding  system  may  look  more  attractive  in  a benign  environment 
than  in  an  operational  environment. 

SOTAS  provides  a good  example  of  a system  that  must  be  examined  in 
an  operational  environment.  SOTAS  was  designed  to  perform  surveillance  and 
target  acquisition  functions.  In  the  former  role,  SOTAS  monitors  enemy 
activity  in  the  region  lying  beyond  ground  line-of-sight.  In  the  latter  role, 
SOTAS  locates  individual  targets  or  clusters  of  targets  and  transmits  their 
location  to  the  elements  capable  of  responding  with  maneuver  forces  or  weaponry 

Within  the  present  Army  structure,  the  intelligence  branch  is 
responsible  for  surveillance;  the  artillery  branch,  for  target  acquisition. 
Hence,  the  roles  of  SOTAS  cross  current  organizational  lines  and  SOTAS  must 
be  integrated  into  both  organizational  elements.  There  is  then  the  strong 
possibility  that  existing  procedures  and  practices  for  conveying  information 
between  the  organizational  elements  may  offset  some  of  the  advantages  gained 
from  use  of  the  computerized  system.  The  time  saved  by  using  the  system  in 
gathering  and  conveying  information  to  a commander,  for  example,  may  be  of 
relatively  little  advantage  due  to  significant  procedural  delays  in  conveying 
information  between  the  structured  elements. 

The  implications  of  organizational  structure  for  the  ODAP  is  not 
currently  a major  concern,  as  the  ODAP  is  limiting  its  attention  to  assisting 
the  task  force  commander.  Any  extension  of  scope  for  the  project,  however, 
could  make  organizational  structure  a significant  area  of  concern.  The  ODAP 
is  already  studying  ways  to  reorganize  the  task  force  commander's  staff  in 
order  to  more  effectively  use  the  decision  aids  now  under  development. 


2.  System  Role 

The  determination  of  a precise  role  for  a system  such  as  SOTAS 
that  is  to  be  integrated  into  an  existing  command  and  control  structure  is 
a step  that  must  be  taken  in  system  development.  SCTAS  provides  data  from 
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beyond  ground  line-of-sight.  But  for  whom?  And  in  what  form?  In  the  SOTAS 
program,  these  were  questions  that  were  addressed  and  resolved  during  the 
advanced  development  of  the  program.  However,  the  answers  to  such  questions 
are  often  not  only  difficult  but  frequently  changed  during  the  development 
of  a system  as  the  requirements  are  revised.  Although  conceptually  they  may 
appear  to  represent  only  minor  modifications  to  the  system,  operationally 
they  may  represent  very  significant  changes. 


The  problem  of  role  determination  will  likely  soon  confront  the 
ODAP.  A number  of  the  aids  under  development  have  reasonably  clear  appli- 
cations and  the  ODAP  should  give  serious  attention  to  how  they  will  be  inte- 
grated into  the  existing  command  and  control  system.  Problems  in  this  area 
are  almost  certain  to  arise  and  advanced  attention  to  them  can  almost 
assuredly  simplify  the  integration  of  the  aids  into  the  existing  command 
and  control  system. 


Measures  of  Effectiveness 


The  development  of  measures  to  assess  the  effectiveness  of  a sys- 
tem is  a problem  common  to  nearly  all  decision  aiding  systems.  The  develop- 
ment of  such  measures  has  obvious  benefits  to  the  system  designers;  they  can 
use  the  measures  as  criteria  for  developing,  evaluating,  and  improving  the 
system.  They  also  have  the  additional  benefit  that  a commander  is  much  more 
likely  to  respond  favorably  to  a system  if  it  can  be  demonstrated  to  him 
that  he  can  make  decisions  more  effectively  with  the  system  than  without  it. 


The  development  of  measures  of  effectiveness  is  a difficult  under- 
taking for  the  system  designers,  because  they  must  generally  evaluate  a sys- 
tem apart  from  the  command  and  control  system  in  which  it  will  operate. 
Simple  intuitive  measures  of  effectiveness  when  applied  to  an  isolated  sys- 
tem have  often  proved  to  be  unsatisfactory. 

In  systems  such  as  SOTAS,  one  measure  of  effectiveness  might  be 
the  amount  of  information—  i ,e. , the  throughput— made  available  as  a result 
of  using  the  system.  One  might  like  to  say  that  the  more  information  the 


system  made  available,  the  better  the  performance  of  the  system.  SOTAS 
demonstrated  in  at  least  one  instance  that  this  was  not  the  case.  In  that 
instance,  the  transmission  of  data  on  all  detected  moving  targets  (without 
intermediate  editing  to  evaluate  the  military  importance)  overloaded  the 
receiving  tactical  element  and  the  performance  of  the  system  decreased. 

Another  potential  effectiveness  measure  is  the  timeliness  of  infor- 
mation. Timeliness  would  be  of  most  value  against  perishable  targets.  An 
MOE  might  show  that  a significant  reduction  in  processing  time  by  the  system 
would  significantly  increase  the  overall  effectiveness  of  the  combat  forces 
against  perishable  targets.  However,  this  is  also  not  necessarily  true.  For 
example,  as  indicated  earlier,  the  time  required  to  relay  the  information  from 
SOTAS  to  the  controller  responsible  for  assigning  weapons  to  targets,  plus 
the  time  required  for  the  weapons  to  reach  a target  could  exceed  the  time 
available  for  attacking  it. 

Tests  of  the  SOTAS  were  used  to  investigate  the  impact  of  addi- 
tional time  delays  introduced  by  the  normal  processing  channels.  In  some 
instances,  these  time  delays  were  found  to  be  excessive.  As  a consequence, 
the  remote  terminals,  shown  in  Figure  III-l,  were  introduced  into  the  system. 
These  provide  the  forward  forces  with  the  immediate  information  they  require 
to  respond  quickly  and  effectively  to  enemy  action. 


D.  SPECIAL  PROBLEMS 

A number  of  special  issues  are  addressed  in  this  section  that  have  not 
been  covered  in  detail  in  other  parts  of  the  report. 

1.  Other  System  Competition 

The  capabilities  of  other  systems  that  might  perform  roles  similar 
to  the  system  under  development  must  be  assessed.  For  example,  the  primary 
role  of  SOTAS  is  to  gather  data  on  targets  lying  beyond  the  ground  line-of- 
sight.  By  being  positioned  behind  the  FEBA,  it  is  relatively  invulnerable 
to  ground  fire  and  because  of  the  tracker,  it  can  probably  pinpoint  target 


locations  more  accurately  than  other  systems.  Nevertheless,  other  systems 
can  perform  portions  of  the  overall  SOTAS  role,  and  must  be  taken  into 
account  when  evaluating  the  overall  worth  of  the  system. 

At  this  time,  the  issue  of  other  system  competition  is  of  particu- 
lar relevance  to  the  ODAP  in  the  selection  of  potential  aids  for  development. 
With  a potentially  broad  spectrum  of  aids  available,  an  awareness  of  what 
related  work  is  being  performed  elsewhere— even  if  performed  at  a much  lower 
level  of  sophistication  than  in  the  ODAP— would  be  of  considerable  value  in 
selecting  aids  for  development  in  the  program.1 

2.  Field  Testing 

The  developers  of  SOTAS  have  stressed  the  advantage  of  giving  the 
military  commanders,  the  eventual  users  of  the  system,  the  opportunity  to 
appraise  the  system  at  an  early  stage  of  its  development.  By  providing  this 
exposure  to  the  system,  they  felt  they  could  develop  both  a better  system 
and  engender  the  support  of  the  users  for  the  system.  For  SOTAS,  this 
approach  has  been  highly  successful. 


E.  SUMMARY 

This  chapter  concentrated  primarily  on  the  problem  of  interfacing  a 
decision  system  or  set  of  decision  aids  to  an  existing  command  and  control 
structure.  The  development  of  this  interface  represents  an  area  which 
presents  many  problems  of  substantial  difficulty,  which  hinders  the  develop- 
ment of  automated  systems,  and  which  have  been  largely  neglected  by  theoret- 
ical researchers.  In  our  judgment,  it  also  represents  an  area  which  has  not 
been  adequately  addressed  by  the  ODAP.  And  since  it  impacts  significantly 
on  the  feasibility  of  successfully  implementing  the  ODAP  decision  aid 
methodologies,  we  feel  it  represents  an  area  in  which  the  ODAP  could 
profitably  address  greater  attention. 


^ome  of  the  work  is  described  in  this  report.  The  bibliography  contains 
references  to  additional  work  of  potential  interest  to  the  program. 
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IV.  TR1DENT/SSN  COMMAND  AND  CONTROL 


In  the  chapters  on  VTS  and  SOTAS,  we  emphasized  decision  aiding  systems; 
decision  aids  were  discussed  as  they  related  to  those  systems.  In  this 
chapter  the  emphasis  will  be  on  the  decision  aids  themselves,  specifically 
on  those  aids  under  development  for  the  defensive  command  and  control  system 
of  the  TRIDENT  submarine.  Although  strictly  speaking  these  are  aids  for  a 
ship  commander  rather  than  a task  force  commander,  they  provide  an  excellent 
example  of  the  current  state-of-the-art  in  operational  decision  aids.  They 
come  as  close  as  any  operational  aids  we  have  seen  to  those  under  development 
in  the  ODAP. 

In  the  discussion  to  follow,  we  will  explicitly  address  such  questions 


as: 


At  what  level  of  mathematical  sophistication  are  the  aids? 

What  are  the  characteristics  of  the  situations  or  activities  in 
which  the  decision  aids  are  used  that  make  them  attractive  for 
using  aids? 

To  what  extent  could  the  aids  have  been  developed  independently 
of  the  specific  systems  and  then  integrated  into  them? 


In  addition  to  the  development  of  specific  decision  aids,  attention 
has  been  given  in  the  ODAP  to  changes  in  the  organizational  structure  of 
the  commander's  staff  to  accommodate  the  decision  aids.  A related  problem 
area  that  affects  organizational  structure  is  the  physical  configuration  of 
the  decision  aids  within  a command  center — the  physical  location  of  the 
specific  aids,  the  number  of  displays  required,  the  aids  that  can  share 
displays,  and  so  forth.  We  will  outline  the  approach  taken  in  the  SIAC/SSN 
(Submarine  Integrated  Attack  Center)  program  to  illustrate  the  procedures 
that  are  used  in  developing  such  a configuration.  What  will  become  clear 
from  the  discussion  is  the  need  for  considering  the  operational  situation 
in  developing  efficient  configurations. 
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A.  OVERVIEW  OF  DECISION  AIDS 


A modular  approach  was  adopted  in  developing  the  decision  aids  for  the 
defensive  command  and  control  system  in  TRIDENT.  Control  consoles  and  dis- 
play equipment  are  located  in  the  Command  and  Control  Center  (CCC).  A 
separate  module  is  under  development  for  each  of  the  activities  of  the  ship 
requiring  command  decision— search,  track,  torpedo  evasion,  and  so  forth. 

The  modules  are  developed  independently  but  with  predetermined  system  inter- 
faces—input  and  output  data  sets  and  formats— so  that  they  can  be  easily 
integrated  into  the  system.  Modifications  to  a specific  module  can  then 
be  made  without  reference  to  other  modules  in  the  system  and  specific 
modules  can  be  replaced  by  completely  new  ones.  Among  the  command  modules 
in  TRIDENT  are  the  following: 

1 . The  Operations  Summary  Module 

This  module  serves  as  the  principal  means  of  depicting  for  the 
commanding  officer/officer-of-the-deck  (navigator)  the  best  available  infor- 
mation regarding  the  general  tactical  situation  external  to  the  submarine. 

It  functions  as  an  all-source  data  collection  and  display  mode  for  infor- 
mation pertinent  to  the  operations  of  the  ship. 

2.  The  Search  Management  Module 

This  module  provides  the  capability  to  plan  search  procedures 
that  maximize  the  probability  of  detection  of  surface  ships  or  submarines 
reported  or  expected  to  be  within  the  TRIDENT'S  operating  area.  It  permits 
the  operator  to  preview  quickly  the  implications  of  changes  in  own  ship's 
depth,  speed,  and  sonar  configuration  or  sensor  performance.  It  thus  serves 
as  an  aid  to  assist  the  operator  (commander)  in  devising  near  optimal  search 
patterns.  (It  docs  not  devise  the  pattern  for  him.) 

3.  The  Avoidance  Management  Module 

This  module  provides  a capability  to  present  displays  depicting 
the  likelihood  of  counterdetection  of  own  ship.  It  assists  the  operator  in 
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evaluating  depth  and  speed  combinations  for  his  own  ship  that  minimize  the 
probability  of  being  detected  by  a specified  target  type.  Thus,  it  shares 
with  the  Search  Management  Module  the  property  of  serving  as  an  aid  to  assist 
the  operator  in  planning  rather  than  in  automatically  generating  courses 
that  minimize  the  likelihood  of  counterdetection. 

4.  The  Torpedo  Evasion  Module 

This  module  provides  information  displays  for  threat  assessment  and 
countermeasures  (static)  employment  in  the  event  a hostile  weapon  (e.g.,  a 
torpedo)  is  detected  in  the  water.  An  automatic  alert  is  generated  imme- 
diately on  detection.  Geographic  and  depth  separation  displays  are  presented 
to  assist  (once  again)  the  operator  in  formulating  evasive  tactics. 

5.  Defensive  Tactics  Module 
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This  module  provides  the  capability  for  assessing  the  tactical 
situation  with  respect  to  a selected  high  threat  contact  and  for  determining 
presets,  i.e.,  trajectories,  for  the  MOSS  programmable  countermeasure.  MOSS 
is  a deceptive  countermeasure  that  simulates  the  signature  of  the  TRIDENT. 


6.  The  Environmental  and  Data  Entry  Module 

This  module  provides  for  entry  and  initial  processing/filtering 
of  the  environmental  and  own  ship  background  noise  data  for  use  by  the  other 
modules. 

A principal  characteristic  of  the  structure  of  each  of  these 
modules  is  that  they  assist  tb *3  operator  (commander)  in  his  decisionmaking 
process;  they  do  not  make  decisions  for  him.  Perhaps  the  most  likely  candi- 
date for  full  automation  is  the  Torpedo  Evasion  Module.  Here  tht  time  avail- 
able for  making  and  implementing  a decision  may  be  so  short  that  it 
eventually  may  become  necessary  to  develop  a fully  automated  capability. 
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B.  EXEMPLARY  DECISION  AIDS 


We  now  consider  three  specific  decision  aids  which  are  indicative  of 
the  levels  of  sophistication  exhibited  by  current  or  near-term  decision  aids 
and  which  manifest  many  of  the  characteristics  and  problems  associated  with 
such  aids.  At  least  one  of  the  aids— the  aid  for  exploring  the  consequences 
of  adopting  specific  tactics  for  the  MOSS  countermeasure— approaches  the 
level  of  sophistication  of  the  outcome  calculators  under  development  in  the 


The  first  aid,  which  is  in  the  Search  Management  Module,  assists  the 
operator  in  planning  and  conducting  a search.  It  provides  a graphical  dis- 
play of  the  likelihood  that  a target  whose  characteristics  are  specified  by 
the  operator  will  be  detected  by  the  ship's  sensors.  The  computation  of  the 
likelihood  takes  into  account  an  operator  specified  speed,  course,  and  depth 
for  both  the  TRIDENT  and  the  operator  specified  target,  and  the  existing 
environmental  conditions.  The  likelihoods  may  be  displayed  in  either  the 
horizontal  or  vertical  plane.  The  horizontal  display  is  shown  in  Figure  IV-1 


In  the  figure  the  TRIDENT  is  located  at  the  center  of  the  dodecagon. 

The  numbers  at  the  vertices  of  the  dodecagon  denote  the  bearing  of  the  ver- 
tices with  respect  to  the  bow  of  the  TRIDENT.  These  are  expressed  in  degrees 
and  measured  in  a clockwise  direction,  i he  numbers  along  the  x-axis  repre- 
sent range  from  the  ship  in  standard  units.  The  shaded  regions  represent 
areas  in  which  a target  with  the  operator  specified  characteristics  would  be 
detected  with  a probability  greater  than  or  equal  to  50  percent.  (The  inner 
non-shaded  area  might,  for  example,  represent  shadow  zones,  i.e.,  an  effect 
caused  by  bending  of  the  ray  paths  due  to  spatial  variations  in  the  index  of 
refraction.)  Additional  data  are  contained  in  the  upper  and  lower  windows 
which  are  blanked  out  in  the  figure.  Included  in  the  data  are  own  ship  and 
target  depth  and  speed,  maximum  sonar  range,  and  assumed  sonar  configurations, 

The  vertical  display  can  also  be  used  to  show  counterdetection  prob- 
abilities assuming  the  best  mode  of  propagation— as  selected  by  operator— 
between  own  ship  and  target.  The  more  complete  all  aspect  return,  counter- 
detection probabilities  are  calculated  using  decision  aids  in  the  Avoidance 
Management  Module. 
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The  second  decision  aid  we  will  describe  assists  the  operator  in 
responding  to  an  imminent  undersea  attack.  The  aid  is  part  of  the  Torpedo 
Evasion  Module.  Figure  IV-2  illustrates  the  display  for  a three  torpedo 
attack.  The  circle  marked  by  a cross  in  the  center  of  the  display  is  own 
ship;  the  adjacent  circle  marked  by  an  "E,"  a static  countermeasure.  The 
leader  line  eminating  from  own  ship  denotes  its  current  heading.  The  series 
of  points  to  the  lower  right  of  own  ship  denote  its  previous  positions. 

The  rays  eminating  from  own  ship  and  from  its  previous  positions  indicate 
the  bearing  of  the  torpedos  at  the  corresponding  times.  (In  this  example 
only  the  bearings  of  the  torpedos  are  known.  If  the  ranges  were  also  known, 
circles  indicating  their  position  would  be  shown  on  the  display.)  At  the 
present  time— as  indicated  by  the  three  rays  eminating  from  the  own  ship 
symbol— the  bearing  of  all  three  torpedos  is  shown.  For  previous  times,  only 
the  bearing  of  the  first  torpedo,  which  was  selected  by  the  operator  for  dis- 
play, is  shown.  The  time  profile  of  the  bearing  of  the  first  torpedo  is  also 
shown  in  the  upper  plot.  Over  the  time  interval  covered  by  the  display  the 
true  bearing  has  decreased  from  an  angle  of  about  120  degrees  to  an  angle  of 
about  80  degrees. 

To  the  left  of  the  display  is  depicted  the  depth  of  own  ship,  the  static 
countermeasure,  and  the  three  torpedos.  Torpedos  one  and  two  are  both  at 
a depth  of  200  standard  units;  torpedo  three,  at  100  standard  units.  Additional 
data  shown  on  the  display,  but  blanked  out  in  the  figure,  include  the  status 
of  the  torpedos  and  the  countermeasures.  If  the  torpedos  are  active— i.e., 
emitting— the  frequency,  pulse  width  and  pulse  interval  of  the  torpedo's 
sonar  are  shown. 

Note  that  although  the  decision  aid  does  not  recommend  specific  evasive 
action  to  the  operator,  it  does  present  him  with  all  the  information  available 
on  the  threat  in  a simple,  compact  form.  Using  the  information  on  the  display, 
the  operator  can  draw  a number  of  immediate  conclusions  about  the  status  of 
the  threat.  If  own  ship  has  been  following  a straight  line  course,  the 
operator  can  conclude,  for  example,  that  if  a torpedo  remains  at  a constant 
bearing,  it  is  on  a collision  course;  or,  if  the  bearing  is  rapidly  changing, 
the  torpedo  is  close  to  own  ship. 
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Figure  IV-3  illustrates  a decision  aid  that  permits  an  operator  to 
explore  the  consequences  of  adopting  alternative  tactics  for  mobile  counter- 
measures. This  decision  aid  most  closely  corresponds  to  the  ODAP  definition 
of  an  outcome  generator.  In  the  figure,  the  crossed  circle  denotes,  as 
before,  own  ship;  and  the  series  of  points  eminating  to  the  left,  its 
previous  positions.  The  leader  line  eminating  from  it  denotes  its  projected 
future  positions.  The  circle  containing  the  dotted  "V"  denotes  an  enemy 
contact.  The  leader  line  eminating  from  it  denotes  its  projected  future 
position.  The  lines  projecting  from  the  leader  line  denote  the  bearing  of 
own  ship  and  enemy  contact  for  projected  future  positions.  The  length  of 
the  lines  is  of  significance.  If  the  own  ship  were  to  close  to  within  a 
"line"  of  the  enemy  contact,  its  probability  of  detection  by  the  contact 
would  exceed  50  percent.  So  to  minimize  the  likelihood  of  detection,  own 
ship  should  stay  beyond  the  lines. 

The  line  eminating  to  the  right  of  own  ship  designates  a possible 
tactic  (course)  for  the  MOSS  countermeasure*.  The  tactic  selected— Tactic  6 
in  this  example— is  shown  in  the  table  at  the  top  of  the  display.  Additional 
tactics  are  also  stored  in  the  system  and  may  be  examined  by  the  operator. 

The  purpose  of  the  mobile  countermeasure  (MOSS)  is  to  permit  own  ship 
to  evade  the  hostile  contact.  To  accomplish  this  objective,  the  operator 
selects  a tactic  which  leads  to  a high  probability  of  the  enemy  contact 
detecting  and  tracking  the  MOSS  instead  of  own  ship,  thereby  allowing  own 
ship  to  move  safely  away.  Tactic  6,  displayed  in  the  figure,  moves  MOSS 
well  within  the  50-percent  probability  of  detection  lines,  with  own  ship 
remaining  well  beyond  them.  Tactic  6,  thus,  appears  to  be  a desirable 
tactic  for  evading  the  enemy  contact. 


C.  DISCUSSION  OF  AIDS:  GENERAL  CHARACTERISTICS 

1.  The  situations  or  activities  for  which  the  aids  have  been  devel- 
oped may  be  characterized  as  well -structured,  repetitive-- in  the  sense  they 
may  arise  many  times— and  non-novel  — in  the  sense  they  represent  situations 
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that  could  be  anticipated  ahead  of  time.  To  a large  extent  the  aids  them- 
selves also  represent  the  automation  of  procedures  that  were  formerly  per- 
formed manually  (on  other  shops)  using  tables,  maps,  and  analog  devices 
(e.g.,  slide  rules).  As  a consequence,  the  developers  of  the  aids  dc  not 
encounter  the  type  of  system  integration  problem  encountered  by  SOTAS.  They 
simply  replace  the  officer  who  would  have  performed  the  computations  manually. 


2.  The  level  of  mathematical  sophistication  of  the  decision  aids 
developed  for  TRIDENT  is  significantly  less  than  those  under  development 
for  the  ODAP.  The  detection  probabilities  and  course  projections  required 
for  the  TRIDENT  aids,  for  example,  require  the  use  of  basic,  well-known  detec- 
tion equations  and  tracking  algorithms.  None  of  the  more  sophisticated  tech- 
niques employed  in  the  ODAP— such  as  Bayesian  analysis  or  Von  Neumann- 
Morganstern  Utility  Theory— are  used  in  the  TRIDENT  aids. 


3.  One  of  the  major  problem  areas  involves  the  designing  of  aids  to 
interface  with  the  existing  sources  of  data.  Figure  IV-4  illustrates  the 
wealth  of  data  used  in  calculating  the  detection  areas.  In  developing  the 
aids,  the  practical  problems  associated  with  interfacing  the  aids  apoear  to 
overwhelm  any  theoretical  considerations. 


These  circumstances  illustrate  why  it  is  so  difficult  to  uevelop 
operational  aids  in  isolation  and  then  to  apply  them  in  an  operational  con- 
text. The  data  that  are  available,  their  format,  and  indeed  the  way  in 
which  the  commander  uses  the  data  are  peculiar  to  the  operational  setting, 
i.e.,  the  structure  of  the  aids  depends  on  the  specific  characteristic  of 
own  ship,  the  anticipated  targets,  and  the  form  and  availability  of  data. 


4.  Another  major  problem  area  in  developing  the  aids  lies  in  what  to 
display  and  how  to  display  it.  Basically,  the  operators  are  saturated  with 
information;  they  need  a filtering  process  for  reducing  the  quantity  of  infor- 
mation with  which  they  must  work.  On  the  other  hand,  they  want  access  to  all 
information.  They  are  extremely  reluctant  to  have  information  within  the 
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system  that  is  not  at  their  disposal.  These  seemingly  conflicting  goals 
were  also  encountered  in  VTS  and  SIMTOS,  where  they  were  satisfied  through 
the  use  of  a hierarchical  data  structure,  which  allowed  an  operator  through 
specific  requests  to  the  system  to  access  data  at  any  level  of  detail  he 
chose. 

The  operators  also  have  an  extreme  reluctance  to  allow  decisions 
to  be  made  automatically.  They  want  their  workload  reduced  but  not  their 
decisionmaking  responsibil ity.  The  three  aids  described  in  detail  here 
all  have  this  characteristic.  They  present  the  information  but  leave  the 
making  of  the  actual  decision  to  the  operators. 

D.  DECISION  STYLE 

As  discussed  in  the  last  section,  there  is  considerable  latitude 
in  what  one  selects  for  display  with  the  decision  aids  and  in  how  or.e  chooses 
to  display  it.  This  is  evident  from  examining  any  of  the  three  decision  aids 
described  here.  For  example,  the  representation  of  Figure  IV-1 , in  which 
regions  where  the  probability  of  detection  exceeds  50  percent  are  shaded, 
could  be  replaced  by  a set  of  constant  probability  of  detection  contours. 

One  contour  might  represent  the  10-percent  probability  of  detection  contours, 
the  next  the  20-percent  contour,  and  so  forth.  Which  of  these  formats  is 
more  appropriate  can  be  determined  to  some  extent  by  how  accurately  it  is 
necessary  to  know  the  probabilities  in  order  to  effectively  devise  search 
patterns.  But  more  important  is  probably  the  decisionmaker’s  style.  Some 
decisionmakers  require  very  detailed  information  to  make  a decision;  others 
require  only  an  overall  assessment  of  the  situation.  The  more  detailed 
information  just  gets  in  their  way. 

The  differences  in  "decision  style"  place  a substantial  Durden  on 
system  designers  and  may  result  in  dramatic  increases  in  botn  the  cost  and 
time  required  to  develop  a system.  In  TRIDENT,  for  example,  the  frequent 
turnover  in  Naval  personnel  could  result  in  a significant  restructuring  of 
the  decision  aid  program.  The  new  personnel  have  had  different  experiences, 
think  in  different  ways,  and  have  different  values.  They,  therefore,  likely 
differ  in  what  they  feel  is  suitable  in  a decision  aid. 
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The  most  comprehensive  and  useful  discussion  of  "decision  style"  we 
have  seen  was  done  by  Honeywell  Systems  and  Research  Center  for  the  Army 
Research  Institutes  SIMTOS  program  (see  Chapter  V).  Honeywell  discusses 
"adaptive"  decision  aids,  which  adapt  to  the  decision  style  of  the  user, 
and  "normative"  aids,  which  are  not  adaptable  and  probably  correspond  most 
closely  to  the  decision  style  of  the  system  engineer. 

Honeywell  had  developed  a three-dimensional  characterization  of  a 
prototype  decisionmaker  for  use  in  developing  adaptive  decision  aids.  The 
prototype  decisionmaker  is  characterized  as  abstract  or  concrete,  logical 
or  intuitive,  and  active  or  passive.  The  abstract  decisionmaker,  or  more 
precisely  the  decisionmaker  who  exhibits  the  abstract  rather  than  the 
concrete  characteristic  feels  at  home  with  symbolic  displays;  the  concrete 
decisionmaker,  with  English  language  presentations.  The  logical  decision- 
maker prefers  a hierarchical  structured  data  base,  so  that  he  can  system- 
atically and  methodically  analyze  the  data.  The  intuitive  decisionmaker 
prefers  to  see  an  aggregated  characterization  of  an  engagement  so  that  he 
can  rapidly  infer  what  is  taking  place  and  quickly  arrive  at  a course  of 
action.  The  active  decisionmaker,  presented  with  a keyboard  and  a display, 
leaps  in  and  makes  use  of  all  the  capabilities  the  system  has  to  offer. 

The  passive  decisionmaker  sits  back  and  quietly  observes  the  information 
presented  to  him.  He  prefers  to  see  a lot  of  information  in  the  basic 
display,  automatic  prompting,  and  the  like. 

As  this  short  discussion  indicates,  the  decision  aid  structure  that 
appeals  to  a particular  decisionmaker  and  with  which  he  can  work  most 
effectively  varies  with  his  style.  The  source  of  many  of  the  problems  that 
arise  in  the  development  of  decision  aids  appears  to  arise  from  this  diver- 
sity of  decision  styles.  This  suggests  that  the  development  of  adaptive 
decision  aids  appears  to  have  advantages  not  only  in  an  increased  accept- 
ability of  the  aids  but  in  increased  effectiveness  and,  in  the  long  run, 
in  the  time  and  cost  required  for  development. 


49 


I I 


E.  SIAC/SSN  DECISION  AID  CONFIGURATION 


Our  discussion  thus  far  in  this  chapter  has  been  restricted  to  the 
characteristics  of  individual  decision  aids.  There  are  also  additional 
topics  that  pertain  to  the  acceptance  and  utility  of  decision  aids  that 
could  be  usefully  addressed.  The  question  of  changes  in  organizational 
structure  of  the  commander's  staff  is  one  topic  of  interest.  This  topic 
has  been  addressed  by  ODAP.  Another  topic  of  interest  relates  to  the 
configuration  of  the  decision  aids  within  the  command  center.  This  topic 
will  be  addressed  here.  We  are  particularly  interested  in  demonstrating 
the  very  close  relationship  between  the  configuration  adapted  for  the  aids 
and  the  operational  situation  in  which  the  aids  will  be  employed. 


We  will  briefly  describe  the  approach  taken  in  the  SIAC/SSN  (Submarine 
Integrated  Attack  Center)  program  to  configure  the  decision  aids  within  the 
Atcack  Center  of  the  SSN  700  class  submarines  to  optimize  their  usage  by  the 
commanding  officer.  Many  of  the  aids  for  the  SSN  700  class  submarine  are 
similar  or  identical  to  those  for  the  TRIDENT. 


The  objective  in  configuring  the  aids  in  the  Attack  Center  of  the  SSN 
were  (1)  to  position  the  aids  so  that  tne  aids  with  the  greatest  use  were 
nearest  the  commander;  (2)  to  position  those  aids  that  would  be  used 
together  or  sequentially  near  one  another;  and  (3)  to  minimize  the  number 
of  displays  required.  The  achievement  of  the  final  objective  required  a 
determination  of  which  aids  required  separate  displays  and  which  aids— 
using  a window  concept,  for  example,— could  be  simultaneously  shown  on  a 
single  display. 


The  approach  used  to  determine  tne  arrangement  of  the  aids  was  to 
devise  three  "typical"  scenarios  (in  the  SIAC/SSN  program  they  were 
referred  to  as  operational  scenarios)  and  then  observe  in  a simulation  the 
sequence  of  activities  a commander  followed  in  conducting  the  activities 
required  by  the  scenarios.  The  three  scenarios  used  were: 
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The  submarine  proceeds  from  transit  depth  to  periscope 
depth  and  back  to  transit  depth.  The  activity  is  performed  by 
the  00D  who  must  communicate  with  the  commanding  officer,  who 
is  not  in  the  Attack  Center. 


The  submarine  is  engaged  in  a non-aggressive  barrier  patrol. 
The  activities  involve  primarily  the  surveillance  function 
with  emphasis  on  search,  track,  identification,  target  motion 
analysis,  and  communications. 


The  submarine  launches  its  weapons  against  a designated  target. 
Prelaunch  and  postlaunch  tactics  are  considered  for  the  sub- 
marine. Emphasis  is  on  environmental  conditions,  search, 
target  motion  analysis,  approach,  geographical  situation,  attack, 
weapon  employment,  and  evasions. 


Each  of  these  scenarios  requires  an  increasing  number  of  activities. 
As  a group  they  provide  a reasonably  comprehensive  picture  of  the  normal 
functions  of  the  commander  (000). 


For  each  scenario  a surprising  number  of  activities  are  required.  In 
the  first  scenario,  for  example,  activities  range  from  simply  assessing  the 
navigational  situation  to  examining  environmental  and  search  data,  to  making 
course  changes  required  to  check  the  sonar  blind  zone  astern,  to  communi- 
cating requests  for  performing  particular  activities  to  the  commanding 
officer,  to  visual  searching  of  the  surface  using  the  periscope,  to  moni- 
toring of  sonar  source  contacts,  and  to  the  performing  of  the  activities 
necessary  for  return  to  transit  depth. 

Equipment  involved  in  these  activities  includes  such  items  as  periscope 
bearing/range  indicator,  weapon  control  console,  plotter,  low  light  level 
television,  chart  table,  fathometer,  and  radar  and  sonar  display  equipment. 


Once  the  scenarios  are  designed  and  the  simulations  conducted  and 
observed,  the  subsequent  analysis  is  straightforward.  As  a first  step, 
sequence  diagrams  are  constructed  that  show  movement  of  the  commanding 
officer  from  area  to  area  and  equipment  used  in  each  area  while  performing 
a given  activity.  From  the  sequence  diagrams  histograms  can  be  constructed 
showing  for  each  or  all  three  scenarios,  the  number  of  accesses  to  each 
item  of  equipment,  the  number  of  times  that  pairs  of  equipment  are  used 
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in  sequence,  the  number  of  times  pairs  of  equipments  were  used  together 
(simultaneous  usage),  and  the  percentage  of  time  one  display,  two  displays, 
etc.  were  simultaneously  in  use. 

With  this  information— gathered  from  close  observation  of  operations— 
efficient  decision  aid  configurations  can  be  devised. 

The  important  point  here— as  it  has  often  been  elsewhere  in  the  report— 
is  that  to  effectively  develop  an  operational  system  one  must  be  in  close 
touch  with  the  operational  situation.  Without  such  contact  it  is  nearly 
impossible  to  develop  a successful  system. 


F.  SUMMARY 

In  this  chapter  we  have  used  the  TRIDENT  to  exhibit  the  present  (or 
near-term)  status  of  decision  aids  in  operational  systems.  We  found  that 
for  the  aids  the  most  difficult  problems  were  concerned  with  what  to 
display,  how  to  display  it,  and  how  to  integrate  the  aids  into  the  existing 
command  and  control  structure.  For  each  of  the  aids  we  also  found  the  level 
of  mathematical  sophistication  was  substantially  less  than  for  the  aids 
under  development  in  the  ODAP.  In  this  chapter  we  also  examined  the  con- 
figuration of  the  decision  aids  within  a command  (attack)  center.  We 
found  that  a solid  familiarity  with  the  operational  situation  was  necessary 
in  order  to  develop  efficient  decision  aid  configurations. 
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V.  SIMULATED  TACTICAL  OPERATIONS  SYSTEM  (SIMTOS) 


; . The  Simulated  Tactical  Operations  System  (SIMTOS)  was  developed  by  the 

Army  Research  Institute  to  assist  in  the  development  and  study  of  computer- 
] ized  tactical  command  and  control  systems.  It  differs  from  systems  devel- 

oped for  operational  deployment,  such  as  those  considered  in  earlier  chapters, 
| in  that  it  is  a research  tool  intended  for  the  study  of  data  base  organiza- 

* r 

tion  and  processing,  decision  aids,  and  the  more  general  problem  of  human- 
j computer  interaction  in  tactical  C2  systems. 

I * 

The  approach  taken  in  developing  SIMTOS  and  the  lessons  learned  in 
: using  the  system  should  be  of  particular  interest  to  the  ODAP.  The  ODAP  is 

currently  setting  up  a simulation  system  at  the  University  of  Pennsylvania 
for  the  purpose  of  testing  and  evaluating  the  decision  aids  under  develop- 
**  ment  in  the  program. 
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A.  BACKGROUND 

In  the  late  1960s,  a collection  of  off-the-shelf  hardware  was  assembled 
and  installed  in  selected  7th  Army  headquarters  in  Europe  as  part  of  an  eval- 
uation of  the  role  of  automation  in  tactical  commands.  ARI  participated 
in  the  evaluation  of  many  of  the  human  factors  aspects  of  the  system.  Many 
problems  were  uncovered  as  the  system  evolved,  and  though  verifying  the 
utility  of  automation  in  an  operational  environment,  it  was  clear  additional 
effort  would  be  required  for  detailed  system  definition  and  requirement 
specification.  The  hardware  was  sent  to  Ft.  Hood  where  it  served  for  sev- 
eral years  as  a test  bed  for  continued  system  development.  In  parallel 
with  their  participation  at  Ft.  Hood,  ARI  began  the  development  of  SIMTOS 
to  serve  as  a man-in-loop  research  vehicle  which  would  permit  controlled 
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research  on  the  human  aspects  of  the  use  of  computers  in  a tactical  envi- 
ronment without  undue  confounding  of  variables  and  other  practical  con- 
straints imposed  by  a field-test  environment.  SIMTOS  has  undergone  con- 
tinuous development  and  use  throughout  the  1970s. 


B.  CHARACTERISTICS  OF  SYSTEM 

SIMTOS  simulates  an  attack  of  a Warsaw  Pact  Combined  Arms  Army  on  a 
U.S.  Army  division  in  the  Hof  Gap  area  of  the  Central  European  theater. 

For  the  simulation  an  individual  player  assumes  the  functions  of  the 
G-3  (operations  officer)  and  also  some  of  the  functions  of  the  commanding 
officer.  He  may  play  either  the  offensive  or  defensive  role.  The  simu- 
lation itself  plays  the  role  cf  the  side--U.S.  or  Warsaw  Pact— not  played 
by  the  subject.  The  attack  itself  is  divided  into  a planning  phase  and 
an  execution  phase.  During  the  planning  phase  the  G-3  performs  such 
functions  as  the  prepositioning  of  forces,  the  determination  of  force 
boundaries,  and  the  assignment  of  firepower  (tank  company  A to  brigade  B). 
During  the  execution  phase,  he  performs  such  functions  as  the  commitment 
and  withdrawal  of  forces  and  the  direction  of  artillery  fire  (strictly 
speaking,  a function  of  the  artillery  officer). 

All  combat  activity  is  played  by  the  simulator.  Combat  algorithms 
are  included  to  describe  force  movement,  attrition,  and  tactical  decision 
making.  A decision  to  fire,  for  example,  is  based  on  whether  a “circle 
of  influence"  associated  with  a friendly  force  element  overlaps  an  enemy 
force  element. 

Hardware  for  the  simulator  includes  a CDC  3300  computer  and  two 
CRT  displays. 

In  the  development  and  subsequent  use  of  SIMTOS,  the  greatest  atten- 
tion has  been  given  to  the  content,  structuring,  and  processing  of  the 
data  base  for  the  system.  The  guiding  principles  in  developing  the  data 
base  were  (1)  to  include  information  a commander  might  receive  from  his 
staff,  and  (2)  to  organize  it  in  a manner  that  simulates  the  commander 
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speaking  to  his  staff.  The  application  of  these  principles  led  to  a 
hierarchical  data  base  structure.  The  highest  level  in  the  hierarchy  cor- 
responds to  the  commander's  staff  officers--personnel , intelligence,  oper- 
ations, logistics,  and  so  forth.  At  the  next  level,  under  intelligence  for 
example,  are  order  of  battle  data  and  under  it  information  on  the  strengths 
and  dispositions  of  the  forces.1 

The  SIMTOS  designers  have  devoted  considerable  effort  to  decision  aids 
that  assist  in  processing  the  data  base.  Since  the  number  of  levels  in  the 
data  base  may  reach  10  or  11,  and  a user  must  proceed  level  by  level  down 
the  hierarchy  to  reach  a particular  data  element,  many  of  the  aids  are 
directed  at  simplifying  and  speeding  up  this  data  retrieval  process. 

One  of  the  simplest  aids  is  a natural  consequence  of  structuring  the 
data  base  along  the  lines  of  the  commander's  staff.  Data  at  the  upper 
levels  are  aggregations  of  more  detailed  data  at  lower  levels  of  the  hier- 
archy. For  example,  the  total  number  of  forces  in  a division  are  at  one 
level,  whereas  at  the  next  lower  level  the  number  is  broken  out  into  the 
number  of  forces  in  each  brigade.  Thus,  data  of  most  general  interest  is 
found  at  the  higher  levels  of  the  hierarchy.  Deeper  penetrations  into 
the  hierarchy  would  generally  be  made  when,  in  examining  the  data  at  one 
level  of  detail,  a player  decides  he  wants  a more  detailed  breakdown  and 
proceeds  one  step  deeper  into  the  hierarchy.  The  player  would,  therefore, 
seldom  need  to  jump  directly  to  a lower  level  of  the  hierarchy. 

More  fowial  aids  also  have  been  developed  to  simplify  access  to  the 
data  base.  One  of  these  uses  preassigned  indices  to  anticipate  likely  entry 
points  in  the  data  base;  a player  simply  specifies  an  index  and  a jump  is 
immediately  made  by  the  system  to  the  desired  access  point.  A more  sophis- 
ticated version  of  the  aid  uses  a dynamic  indexing  scheme;  when  an  initial 
entry  is  made  by  the  player  to  an  access  point,  an  index  is  automatically 


!The  hierarchical  data  base  structure  described  here  is  reminiscent  of  the 
indexed  sequential  file  method  used  in  data  management  systems  on  most 
third  generation  computers. 
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assigned  by  the  system  to  the  point.  Then  for  future  entries  the  player 
need  only  specify  the  assigned  index  and  he  will  be  automatically  trans- 
ferred to  the  desired  access  point. 

In  addition  to  the  two  direct  access  aids,  another  access  aid  that  is 
receiving  attention  in  SIMTOS  provides  a map  of  the  data  base  structure, 
so  that  a player  knows  where  to  look  to  locate  particular  information  of 
interest.  In  its  present  form,  a "transfer  function"  is  used  in  lieu  of  a 
map.  The  transfer  function  may  be  selected  at  certain  designated  access 
points  within  the  data  base.  Selection  of  the  transfer  function  auto- 
matically transfers  a user  to  another  access  point  that  has  been  predeter- 
mined to  contain  information  "probably  of  interest"  to  anyone  who  found 
the  data  at  the  initial  access  point  of  interest. 

The  general  structure  of  the  data  base  exhibits  a principle  that  has 
been  strongly  endorsed  by  everyone  with  whom  we  have  spoken:  a decision 
aiding  system  should  have  the  property  that  a user  can  "disaggregate" 
the  aggregated  data  normally  prepared  by  a system  to  any  level  of  detail 
he  chooses,  i.e.,  virtually  back  to  the  original  raw  data.  Most  system 
developers  believe  that  this  is  a necessary  characteristic  of  a system 
if  it  is  to  be  successful. 

Now  let  us  consider  the  operation  of  the  system.  As  we  described 
earlier,  the  simulation  is  divided  into  a planning  and  an  execution  phase. 
In  the  planning  phase  the  player  assigns  forces,  fores  boundaries,  and 
firepower.  He  does  this  by  responding  to  multiple  choice  questions  posed 
by  the  simulator.  In  determining  force  boundaries,  for  example,  the 
simulator  asks  which  of  the  three  possible  lines  should  mark  the  forward 
edge  of  his  forces.  The  player  selects  one  of  the  three  options,  and 
the  simulator  proceeds  to  pose  additional  questions  until  the  planning 
phase  is  completed. 

An  additional  feature  that  the  developers  would  like  to  have  in  the 
planning  phase  is  a capability  for  the  system  to  make  recommendations. 

For  example,  they  would  like  the  system  to  have  a capability  to  recom- 
mend, based  on  likely  targets  and  the  environmental  features,  the  type  of 
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artillery  that  should  be  assigned  to  a particular  area.  This  feature,  in 
which  well -structured  problems  with  "textbook"  solutions  are  handled  by  the 
computer,  should  considerably  improve  the  decision  aiding  capability  of  the 
system.  It  should  permit  the  G-3  to  have  more  time  to  devote  to  other 
problems. 

In  the  execution  phase  the  player  makes  decisions  relative  to  the  com- 
mitment and  withdrawal  of  forces  and  the  assignment  of  artillery.  Both 
CRTs  are  used  in  this  phase.  One  of  the  CRTs  is  used  as  a status  board  to 
keep  the  player  apprised  of  the  state  of  both  the  friendly  and  hostile 
forces.  The  status  board  has  a matrix  format  with  unit  designators  denot- 
ing the  rows  and  units  attributes  such  as  strength  and  location  denoting 
columns.  When  a change  occurs,  e.g.,  a change  in  the  strength  of  unit  A, 
a light  associated  with  the  unit  flashes  to  inform  the  player  of  the  change. 
The  player  may  then  elicit  further  information  from  the  system  on  the  mis- 
sion and  detailed  status  of  the  unit. 

A potential  limitation  of  the  automatic  prompting  feature  is  that  many 
lights  may  be  lit  at  the  same  time  and  the  system  does  not  indicate  which 
of  them  are  the  more  critical.  (Recall  that  for  VTS  if  two  collisions  were 
imminent,  the  one  with  the  shorter  time  to  collision  received  the  higher 
priority  and  was  so  indicated  on  the  working  display.)  In  practice,  the 
lack  of  a priority  scheme  does  not  seem  to  be  a serious  problem,  for  the  G-3 
is  constantly  aware  of  which  units  are  engaged  and  of  how  the  overall  situ- 
ation is  developing.  Based  on  this  knowledge  and  on  his  experience,  he  can 
generally  infer  which  events  are  potentially  more  significant  and  examine 
these  first. 

In  the  execution  phase  the  second  CRT  provides  the  G-3  with  a capa- 
bility to  pose  questions  to  the  system  of  a prespecified  form.  For  example, 
in  targeting,  the  G-3  may  specify  that  he  wishes  to  fire  at  target  A and 
would  like  a list  of  the  specific  weapons--based  on  their  location--capable 
of  firing  at  the  target.  The  system  will  provide  him  with  the  list. 
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D.  DISCUSSION 


1 . Measures  of  Effectiveness 

For  a system  such  as  SIMTOS  to  be  successful,  the  commanders  in 
the  field  must  be  convinced  that  the  system  (or  the  concepts  contained  with- 
in the  system)  will  assist  them  in  making  decisions  better  or  more  quickly. 
Frequently,  however,  selling  a person  with  :>n  operational  background  on 
the  value  of  such  a system  is  extremely  difficult  and  sometimes  impossible, 
for  any  deviation  of  the  simulator  from  strict  reality  may  be  perceived  as 
a fatal  weakness  of  the  system.  The  operationally-oriented  person  often 
cannot  accept  (or  chooses  not  to)  any  approximate  representation  of  reality. 

In  SIMTOS  the  problem  is  illustrated  by  the  G-3,  who  plays  in 
addition  to  his  own  role,  those  of  the  artillery  officer  and  the  division 
commander.  As  a consequence,  a commander  may  conclude  (or  claim)  that  the 
differences  between  the  real  world  and  the  simulatic'.  are  sufficiently 
great  that  no  credibility  can  be  ascribed  to  the  simulation. 

For  the  system  developer,  the  message  is  that  he  should  make  every 
attempt  to  make  those  aspects  of  a system  that  are  readily  accessible  to 
operational  personnel  correspond  as  closely  as  possible  to  the  real  world, 
even  if  it  seems  to  him  unnecessary  to  do  so.1 

A second  problem,  which  bears  heavily  on  the  credibility  of  sys- 
tems like  SIMTOS,  is  concerned  with  the  selection  of  the  subjects  for  the 
experiments. 


Experience  suggests  that  the  more  closely  an  analysis,  model  or  the  like 
approaches  reality,  the  better  prepared  the  analyst  needs  to  be  to  discuss 
the  implications  of  small  deviations  from  reality.  The  operations  person- 
nel, feeling  more  at  home  with  the  subject  matter,  come  "alive"  in  presen- 
tations and  subject  the  analyst  to  much  more  careful  scrutinizat'on  than 
when  the  subject  is  of  a more  theoretical  nature,  in  which  case,  the  oper- 
ational personnel  feel  less  capable  of  (or  interested  in?)  examining  the 
results  more  critically. 
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Operational  personnel  who  have  had  experience  in  the  operational 
setting  in  which  the  system  would  be  used  are  not  available  for  the  exper- 
iments. In  the  case  of  SIMTOS,  G-3s  with  operational  experience  in  Europe 
are  not  available  Their  numbers  are  very  limited  and  they  are  being 
groomed  for  higher  level  positions.  Hence,  one  is  left  with  a sense  of 
uneasiness  that  factors  critical  to  the  successful  operation  of  a real 
tactical  operations  system  have  not  been  fully  taken  into  account  in  the 
simulation.  Under  such  circumstances,  the  best  one  can  do  is  select  the 
best  personnel  available.  SIMTOS  has  done  very  well  in  this  regard.  In 
place  of  the  actual  G-3s  they  have  used  graduates  of  the  Command  and 
General  Staff  College,  who  appear  to  be  excellently  qualified  for  the 
experiments. 

A final  problem  associated  with  measures  of  effectiveness 
concerns  the  use  of  scenarios.  Considerable  care  must  be  taken  in  their 
construction,  so  as  not  to  unfairly  bias  thr  evaluations  of  a decision 
system.  In  one  set  of  scenarios  used  in  experiments  with  SIMTOS,  it  was 
found  that  the  results  of  combat  were  largely  insensitive  to  specific 
decisions  made  by  the  G-3.  The  utility  of  the  decision  aiding  system  for 
these  scenarios  was  therefore  small. 

The  message  for  the  system  developer  is  quite  clear: 

Although  one  wants  to  be  assured  that  the  scenarios  one  constructs  are 
realistic,  one  also  wants  to  construct  them  so  that  the  outcome  of  the 
combat  depends  on  the  commander's  decisions.  Only  in  this  way  can  the 
system  be  evaluated  fairly. 

2.  Perfect  Information 

In  Chapter  II  on  the  Standoff  Target  Acquisition  System  (SOTAS), 
we  $trrssed  the  problems  associated  with  the  filtering  and  evaluating  of 
information.  We  also  pointed  out  that  relatively  little  work  had  been 
done  on  these  problems  compared  with  the  effort  devoted  to  the  development 
of  efficient  management  information  systems.  SIMTOS  provides  us  with  an 
explicit  example  of  this  emphasis  on  information  handling  vis-a-vis 
information  filtering  and  evaluations.  As  presently  configured,  the  G-3 
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has  full  knowledge  of  the  status  of  both  forces.  He  is  not  faced  with 
time  delays  in  receiving  information,  incomplete  information,  misleading 
information,  or  uncertainties  in  the  information  he  receives. 

The  developers  of  SIMTOS  recognize  the  limitations  that  working 
only  with  perfect  information  imposes  on  their  studies,  but  feel  that  much 
can  be  learned  about  the  decisionmaking  process  within  these  constraints. 

For  example,  their  current  goal  is  to  determine  what  data  a commander  typ- 
ically uses  in  making  decisions.  Their  approach  is  to  provide  all  the  data 
a commander  might  conceivably  use,  to  observe  what  data  he  actually  uses, 
and  then  to  use  this  information  for  structuring  future  data  bases. 

Although  not  yet  implemented,  the  developers  of  SIMTOS  have 
developed  an  approach  for  introducing  time  delays  and  uncertainties  into 
the  system.  Their  plan  for  handling  time  delays  is  to  maintain  in  the  sys- 
tem historical  force  status  records  extending  back  over  one  or  more  time 
periods.  Although  greatly  increasing  storage  requirements,  this  approach 
will  permit  the  system  to  display  to  the  G-3  time  delayed  force  status  data, 
while  at  the  same  time  continuing  the  "real  time"  development  of  the  conflict. 
The  developers  will  use  standard  techniques— e.g. , the  use  of  normal  distri- 
butions and  sampling  procedures— to  introduce  uncertainties  in  the  values  of 
the  force  status  variables  into  the  system. 


3.  Data  Base  Preparation 

One  particularly  troublesome  feature  of  SIMTOS  and  other  similar 
tactical  operations  systems  is  the  large  data  base  required  and  large  amounts 
of  time  and  effort  required  to  prepare  it.  There  is  little  problem  for 
situations  like  the  Hof  Gap  where  one  can  essentially  do  the  necessary  pre- 
planning and  preparation  essentially  years  in  advance;  but  in  a dynamically 
evolving  war  the  requirements  for  continuing  on  the  spot  preparation  of  the 
data  base  would  probably  make  a system  like  SIMTOS  unusable.  Much  greater 
attention  needs  to  be  given  to  building  a data  base  "on  the  run"  and  to 
using  a partially  filled  data  base. 
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Aids  should  be  developed  to  provide  information  on  what  data  is 
currently  available  in  the  data  base,  what  needs  to  be  added,  and  what 
conclusions  can  be  drawn  from  the  available  data.  In  addition,  decision  aids, 
such  as  those  under  development  for  the  ODAP,  should  be  examined  to  assess 
their  utility  in  the  presence  of  limited  data  and  to  determine  how  they 
might  be  modified  to  be  most  useful  in  a data-limited  situation. 


Color  Graphics 

Although  we  were  impressed  by  the  overall  system,  we  found  the 
SIMTOS  environment  austere,  in  that  two  black  and  white  CRTs,  even  when 
augmented  by  a large  wall  map,  did  not  seem  to  give  a user  a sense  of  being 
in  close  touch  with  the  battlefield.  We  were  thus  pleased  to  see  ARI's 
work  in  color  graphics,  much  of  which  will  be  integrated  into  SIMTOS. 

The  heart  of  the  ARI  color  graphics  system  involves  a conceptually 
simple  but  nevertheless  difficult  to  implement  concept.  A color  television 
camera  is  focused  on  a large  multicolored  wall  map.  The  section  of  the 
map  within  the  field-cf-view  of  the  camera  is  then  projected  on  to  the  screen 
of  a color  television  set.  The  position  of  the  camera  relative  to  the  wall 
map  is  maintained  automatically  by  the  system.  This  permits  the  system  to 
relate  any  point  on  the  screen  to  the  corresponding  coordinates  on  the  map. 
(The  map  is  stored  internally  within  the  computer.)  Thus,  if  an  operator 
using  a light  pen  designates  a road  junction  on  the  screen,  the  system  is 
able  to  relate  automatically  the  point  to  the  road  junction  on  the  internally 
stored  map.  This  conceptually  simple  feature  is  responsible  for  many  of  the 
sophisticated  capabilities  of  the  color  graphics  system. 

Two  simple  outcome  generators  were  demonstrated  for  us  using  the 
color  graphics  system.  The  first  was  a network  analyzer.  This  aid  assisted 
an  operator  in  moving  combat  units  to  various  objectives,  so  as  to  minimize 
the  overall  time  of  transit.  After  the  operator  selects  an  area  of  the 
map  for  examination,  the  aid  automatically  superimposes  the  network  of 
roads  in  the  area  on  to  the  map  with  different  classes  of  roads  being 
designated  by  different  color  lines.  Using  a hook,  the  operator  may  add 


62 


[ 


I 

g 


i. 


I 


I 


i | 

t « ttr 


f 

X 


I 

I 


I 


new  roadways  or  delete  existing  ones  and  select  initial  positions  for  uni^s 
and  objectives  for  them  to  reach.  The  analyzer  then  automatically  selects 
and  displays  routes  for  the  units  to  follow  in  order  to  minimize  the  times 
to  the  objectives.  If  the  operator  finds  a particular  solution  u 'acceptable, 
he  may  add  or  delete  additional  roads  and  rerun  the  algorithm. 

The  second  outcome  generator  demonstrated  for  us  was  a center  of 
mass  generator.  A set  of  observations  of  vehicle  movements— color  coded 
according  to  time  of  observation— was  displayed  on  the  screen.  The  operator 
selected  an  observation  time  and  drew  a "fence"  around  a group  of  obser- 
vations that  appeared  to  form  a fairly  natural  grouping.  The  system  then 
found  the  center  of  mass  for  these  observations.  The  operator  then 
repeated  the  procedure  for  a later  time  and  for  a group  of  observations  that 
looked  as  if  it  might  represent  the  same  grouping.  The  system  then  found 
the  center  of  mass  for  these  observations.  Proceeding  in  this  manner,  the 
operator  plotted  and  projected  the  route  of  the  force.  After  the  operator 
had  examined  several  groupings,  it  became  apparent  that  the  observations 
corresponded  to  a large  force  approaching  and  deploying  for  a river  crossing. 

The  addition  of  color  graphics  to  SIMTOS  would  largely  remove  our 
concerns  about  the  present  austerity  of  the  system.  As  a first  step,  a 
multicolored  map  displaying  status  and  progress  of  the  battle  could  be  added 
to  the  system.  The  type  of  forces,  the  age  of  the  data,  and  the  like  could 
be  differentiated  by  color  coding.  Using  the  hook,  the  operator  could  move 
forces  about  the  battlefield  to  assess  the  attractiveness  of  possible 
redeployments.  It  would  then  also  be  possible  to  develop  much  more  powerful 
analytical  tools.  For  example,  once  uncertainty  is  introduced  into  SIMTOS, 
an  operator  could  use  the  system  to  explore  candidate  strategies  for  his 
forces.  He  would  make  his  best  estimates  of  the  locations  and  strength 
of  his  and  the  enemy's  forces,  ascribe  an  objective  to  the  enemy— e.g., 
the  taking  of  a bridge— and  then  have  the  system  play  the  strategies  using 
his  estimate.  After  he  has  explored  a few  candidate  strategies,  he  would 
select  one  for  his  actual  strategy.  The  system  would  then  play  his  strategy 
against  the  actual  disposition  and  objectives  of  the  enemy  forces. 
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This  type  of  procedure  would  thus  provide  a vehicle  for  exploring  the  impact 
of  uncertainty  on  the  decisionmaking  process. 


With  these  additions,  it  seems  to  us  that  SIMTOS  will  provide  a 
powerful  tool  in  the  development  of  tactical  operations  systems  and  perhaps 
contribute  substantially  to  the  training  of  officers. 


SUMMARY 


The  design,  development,  and  implementation  of  SIMTOS  provide  an 
excellent  case  study  of  the  structuring  and  processing  of  a data  base  for 
use  in  a tactical  operations  system.  The  hierarchical  structure,  which 
simulates  an  officer  speaking  to  his  staff,  is  particularly  attractive. 
When  augmented  by  the  color  graphics,  SIMTOS  should  provide  a powerful 
research  tool  for  studying  many  of  the  problems  that  arise  in  the  develop- 
ment and  use  of  tactical  operations  systems. 


F.  SOURCES 


Dr.  Stan  Hal  pin.  Army  Research  Institute,  is  in  charge  of  SIMTOS 
development.  Documentation  includes  the  draft  report:  Development  and 
Application  of  Decision  Aids  for  Tactical  Control  of  Battlefield  Operations, 


prepared  by  Honeywell  Systems  and  Research  Center  for  ARI  under  contract 
DAHC-19-75-C-0008,  UNCLASSIFIED. 
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VI.  NAVY  SURFACE  SHIP  COMBAT  DIRECTION  SYSTEMS 

In  this  section,  we  discuss  the  combat  direction  systems  employed  on 
U.S.  Navy  surface  ships.  The  term  "combat  direction  system"  refers  to  that 
portion  of  the  combat  system  of  a ship  concerned  with  the  collection,  trans- 
mission, processing  and  display  of  information.  The  Naval  Tactical  Data 
System  (NTDS)  is  an  important  element  of  most  combat  direction  systems. 

The  combat  direction  systems  are  of  considerable  importance  to  the 
ODAP,  for  they  are  the  source  of  a large  part  of  the  tactical  data  available 
to  the  commander.  Furthermore,  combat  information  systems  are  the  area  in 
which  most  commanders  and  their  staff  will  have  had  prior  experience  in 
automated  data  processing.1 

A.  BACKGROUND2 

The  primary  function  of  a combat  direction  system  is  to  provide  the 
commander  with  the  information  he  needs  to  maneuver  his  ship  and  to  employ 
its  weapons  in  a combat  environment.  Prior  to  World  War  II  this  function 
was  performed  by  the  commander  himself  with  the  support  of  a limited  staff. 
With  the  vast  increase  in  the  rate  of  data  input  associated  with  the 


:A  number  of  aspects  of  combat  direction  systems  of  interest  to  the  ODAP 
can  be  discussed  only  at  the  classified  level.  For  those  readers  with 
appropriate  clearances,  we  recommend  Reference  1— Command  and  Staff  Manual 
for  Combat  Direction  Systems  (U)— for  a fuller  treatment  of  combat  directions 
systems  than  we  can  present  here. 

Reference  2 is  the  primary  source  for  the  material  in  this  section. 


scientific  developments  of  World  War  JI . coupled  with  the  changing  nature 
of  the  threat,  the  function  was  assigned  to  a Combat  Information  Center 
(CIC).  Recently,  many  functions  of  the  CIC  have  been  automated. 

The  NOTS  was  initi.-iiy  developed  to  improve  the  data  communication 
within  a ship,  i.e.,  defween  CIC  and  the  weapon  control  system.  It  also 
provided  computer  as.: Stance  for  manual  radar  tracking.  Digital  and  tele- 
type data  links  were  subsequently  added  to  NDT5  to  provide  a capability 
for  transmitting  da*--  between  ships.  During  Vietnam  operations,  sufficient 
tactical  data  was  transmitted  that  a task  force  commander,  located  on  a 
ship  more  than  : 00  miles  from  shore,  could  control  the  air  battle  over  the 
mainland.  T'rp  a>vay  and  presentation  of  the  data  was  sufficiently  impres- 
sive that  ?jme  ship  commanding  officers  actually  left  their  traditional  bat- 
tle station  on  the  bridge  to  work  in  the  CIC. 

The  need  *or  a highly  automated  combat  direction  system  is  becoming 
increasingly  important  as  a requirement  develops  for  simultaneously  handling 
multiple  targets  and  for  a short  reaction  time  response  capability  to 
counter  the  developing  missile  threat. 


B.  SYSTEM  DESCRIPTION 

An  unclassified  description  ofthe  characteristics  of  the  combat/ 
combat-direction  system  currently  being  installed  on  DIG-28  Class  guided 
missile  cruisers  is  contained  in  Reference  3.  This  combat  direction  sys- 
tem is  representative  of  recent  systems  installed  on  surface  ships.  Block 
and  flow  diagrams  for  the  system  are  shown  in  Figures  VI-1  and  VI-2.  The 
major  information  processing  elements  of  the  system  are: 


1 . The  Automatic  Detection  and  Tracking  System  (AN/SPS-48C) 

This  system  represents  a major  improvement  over  previous  systems 
of  this  type.  In  previous  systems,  an  operator  manually  detected  radar 
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V FIGURE  VI-1.  GENERAL  BLOCK  DIAGRAM  OF  DLG-28  CLASS  COMBAT  SYSTEM 
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targets  and,  with  limited  computer  assistaiice,  maintained  target  tracks. 

The  AN/SPS-48C  system: 

• Automatically  processes  radar  video  returns  to  establish 
the  presence  of  targets  within  its  volume  of  surveillance 
responsibility 

• Measures  and  stores  target  position  coordinates  for  all 
target  detections 

• Initiates  and  updates  target  tracks  to  assist  command  and 
control  in  target  definition  and  evaluation 

• Provides  estimates  of  target  velocity  components 

• Uniquely  identifies  each  track  item  for  subseouent  cor- 
relation processing 

• Supports  decision  processing  to  aid  in  the  rejection  of 
false  targets  due  to  noise,  RFI  and  clutter. 

2.  The  Naval  Tactical  Data  System  (NTDS)  Model  IV  Phase  0 

Many  versions  of  NDTS  have  been  developed.  The  system  is  often 
tailored  to  individual  ships  and  is  subject  to  frequent  revisions.  The 
NDTS  scheduled  to  be  deployed  on  the  DLS-28  in  the  1977  time  period  con- 
tains the  following  elements: 

• Information  processing  and  storage  equipment  to  support 
target  definition,  threat  evaluation  and  response  decisions 

t Display  equipment  to  present  processed  information  to  com- 
mand elements  and  to  support  implementation  of  their  decisions 

• Data  conversion  equipment  to  format  incoming  data  for  cen- 
tral processing  equipment  and  to  format  outgoing  data  to 
meet  user  requirements 

• Data  communications  equipment  to  exchange  information  with 
other  units  of  the  fleet 

• Computer  programs  to  provide  for  rapid  information  process- 
ing and  to  support  complex  man-machine  interactive  opera- 
tional requirements. 

3.  The  Weapon  Direction  System  (WPS)  MK-14  Mod  0 

The  DLG  WDS  includes  a general  purpose  automatic  data  processing 
complex,  general  purpose  display  groups,  and  support  software.  It  has  the 
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following  capabilities: 


• Target  and  missile  information  processing  and  display 

• Engageabil ity  calculations  for  selected  targets 

• Resource  sceduling  for  multiple  engagements 

• Missile  communications  for  flight  control 

• General  coordination  of  multiple  weapon  type  responses  to 
the  threat  environment 

• General  management  of  missile  pre-launch  and  post-launch 
control  operations  and  general  management  of  gun  system 
responses 

• Direct  sensor  system  to  weapon  system  interface. 


C.  TRENDS  FOR  DEVELOPMENT  OF  FUTURE  COMBAT  DIRECTION  SYSTEMS 

Reference  4 defines  requirements  for  combat  direction  systems  for  gen- 
eral purpose  forces.  The  following  quotation  discusses  the  role  of  auto- 
mation in  future  systems. 

The  scenarios  commonly  cited  for  possible  naval  con- 
flicts include  situations  of  imposing  complexity. 

Faced  with  the  possibility  of  nearly  simultaneous 
raids  of  surface,  sub-surface,  and  air  launched  anti- 
shipping missiles  (ASM),  naval  task  groups  are  forced 
to  rely  upon  coordinated  defense  so  that  sensors, 
weapons,  and  platforms  of  the  force  may  be  employed 
with  efficiency  and  mutual  support.  The  very  short 
reaction  times  required  for  proper  defense  against 
anti-shipping  missiles  have  forced  the  Navy  to  improve 
early  warning  by  expanding  the  area  of  surveillance, 
and  to  accelerate  the  command  decision  and  weapon 
application  process  through  the  use  of  automation. 

Fortunately,  growing  technology,  particularly  digital 
technology  has  given  us  the  potential  to  keep  pace 
with  these  challenges.  Successful  application  of 
digital  technology  to  the  weapons,  sensors,  combat 
directions,  and  communications  of  fleet  units  enables 
the  design  of  systems  which  can  enhance  operational 
performance,  reliability  and  flexibility.  Digi- 
talization of  combat  functions  can,  if  properly 
implemented,  facilitate  reductions,  both  in  manning 
and  in  the  size,  weight,  and  cost  of  hardware.  There 
are,  however,  the  following  significant  obstacles 
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which  hamper  any  program  to  effect  a sweeping  imple- 
mentation of  digital  technology. 

a.  Resource  Constraints.  The  number  of  pos- 
sible applications  for  digital  integration  and  auto- 
mation exceeds  the  industrial  and  fiscal  resources 
available.  Faced  with  the  prospect  of  continuing 
fiscal  austerity,  the  Navy  has  adopted  a “design  to 
cost"  philosophy,  embracing  both  acquisition  and  life 
cycle  cost  categories,  to  ensure  that  our  scarce 
resouces  are  channelled  into  those  applications  which 
can  demonstrate  the  highest  payoff.  In  this  fiscal 
climate,  combat  systems  and  combat  direction  systems 
must  be  designed  to  a standard  of  adequacy,  rather 
than  maximum  capability. 

b.  System  Complexity  and  Risk.  Overly  ambi- 
tious employment  of  "nice  to  have,"  rather  than 
essential  integration  and/or  innovative  program- 
ming techniques  can  impose  substantial  risks  to 
program  costs  and  schedules  and  should  be  avoided. 

Software  development  for  combat  system  processors 
can  often  become  the  critical  path  of  ship  con- 
struction and  conversion  programs,  particularly  if 
contractual  aspects  of  software  are  not  adequately 
treated.  Programming  complexities  encountered  in 
integrating  new  systems  where  standardization  and 
configuration  control  is  not  or  has  not  been  effec- 
tively realized  often  pose  substantial  obstacles 

to  the  process  of  updating  combat  systems. 

Reference  4 also  contains  the  following  points  of  significance  to  the 
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Systems  shall  be  austerely  designed  but  with  allowance  for  future 
improvements  to  meet  legitimate  emergency  requirements. 

Critical  appraisal  of  digital  data  link  information  flow  is 
required  to  insure  that  essential  information  is  available  for 
display  to  command,  that  tne  system  design  provides  the  neces- 
sary selectivity  and  flexibility,  and  that  the  information 
displayed  does  not  exceed  the  capability  of  the  user  to  absorb 
and  evaluate  the  information. 

Automation  of  subsystem  functions  and  integration  of  subsystems 
should  be  accomplished  where  the  mission  is  essential,  but 
discipline  should  be  exercised  to  keep  the  combat  system  as  simple 
as  requirements  permit. 


D.  SUMMARY 

The  nature  of  the  current  and  projected  threat  to  U.S.  Navy  surface 
ships  requires  the  continued  expansion  and  automation  of  present  combat 
direction  systems  and  their  fuller  integration  with  combat  systems.  Because 
of  the  requirement  for  a high  level  of  system  effectiveness,  constraints 
on  available  resources,  and  the  Navy's  traditionally  evolutionary  approach 
to  system  development,  a carefully  planned  and  closely  controlled  program 
may  be  anticipated.  Combat  direction  systems  thus  provide  a fertile  area 
for  the  application  of  the  decision  aids  developed  by  the  ODAP. 

Future  commanders  and  their  staff  can  be  expected  to  have  familiarity 
with  automated  data  processing  through  their  experience  with  combat  informa- 
tion systems.  This  suggests  that  aids  that  tend  to  fit  in  well  with  combat 
direction  systems  or  appear  to  be  reasonable  extensions  of  them  may  be  the 
most  readily  acceptable  to  a commander  and  his  staff. 
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VII.  ARMY  TACTICAL  DATA  SYSTEMS 


Within  this  category  are  systems  that  support  the  Army  in  the  area  of 
tactical  command  and  control.  Included  are: 

• Tactical  Fire  Detection  System  (TACFIRE) 

• AN/TSQ-73  Missile  Minder 

• Tactical  Operations  Systems  (TOS). . 

Of  these  systems,  TOS  is  the  primary  interest  in  this  study  because  it  is 
intended  to  provide  operational  decision  aids  to  commanders.  The  other 
systems  are  described  briefly  for  the  purpose  of  showing  the  types  of 
tactical  data  systems  developed  by  the  Army. 

The  development  of  all  of  the  systems  listed  above  was  seriously 
hindered  by  difficulties  in  determining  user  requirements.  The  TOS  devel- 
opment history  will  be  discussed  as  an  example. 


A.  TACTICAL  FIRE  DIRECTION  SYSTEM  (TACFIRE) 

TACFIRE  is  the  Army  artillery  equivalent  of  the  Navy  combat  direction 
system.  TACFIRE  is  described  in  Reference  1 as: 

...  a completely  integrated  system  of  tactical 
computer  elements  located  at  the  fire  direction 
centers  of  Active  Army  field  artillery  battalions, 
field  artillery  groups,  division  artilleries,  and 
corps  artilleries  which  will  provide  for  automatic 
transmission,  receipt  and  computation  of  firing  data. 

Field  planning,  processing  of  artillery  target  intel- 
ligence, preliminary  target  analysis,  fallout  predic- 
tions, distribution  of  meteorological  data,  and 
maintenance  of  ammunition  and  fire  unit  status. 

TACFIRE  will  be  interoperable  and  interface  with  the 
Tactical  Operations  System  (TOS)  and  possibly  with 
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other  Army  Tactical  Data  Systems  (ARTADS)  within  the 
conceptual  framework  of  the  Tactical  Command  and  Con- 
trol program  as  they  are  fielded.  TACFIRE  will  use 
an  integrated  system  of  computers,  local  and  remote 
input/output  devices,  digital  storage  and  retrieval 
devices,  display  units  and  control  consoles.  TACFIRE 
will  increase  the  effectiveness  of  field  artillery 
fire  support  through  increased  accuracy,  better  and 
more  rapid  use  of  target  information,  reduced  reaction 
time,  and  greater  efficiency  in  the  determination  of 
fire  capabilities  and  the  allocation  of  fire  units  to 
engage  targets. 

Reference  1 indicates  that  TACFIRE  has  had  limited  procurement.  It 
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is  currently  in  development  and  operational  testing.  Full-scale  production 
is  scheduled  to  begin  in  1978. 


B.  AN/TSQ-73  MISSILE  MINDER 


The  AN/TSQ-73  Missile  Minder  is  a mobile,  easily  transportable,  auto- 
mated air  defense  control  and  coordination  system.  It  will  be  used  by  the 
Army  in  the  field  to  control  and  coordinate  the  fires  of  NIKE  HERCULES  and 
HAWK  surface-to-air  missile  batteries.  It  provides  airspace  surveillance, 
target  tracking,  identification,  display,  and  data  link  communications. 

An  operational  consideration  for  this  system  is  an  interoperability  require- 
ment for  joint  operations  with  Air  Force  units  using  the  Air  Force  Tactical 
Air  Control  System,  Control  and  Reporting  Center  Post  (AN/TSW-91)  and  Marine 
units  using  the  Marine  Air  Command  and  Control  System  (MACCS).  The  AN/TSQ-73 
uses  the  same  technology  as  TACFIRE  and  uses  the  same  basic  processor. 


Reference  1 indicate?  that  the  system  is  scheduled  for  research  and 
development  completion  during  FY  1977.  Production  is  scheduled  for  comple- 
tion in  FY  1979. 
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C.  TACTICAL  OPERATIONS  SYSTEM  (TOS) 

Reference  2 defines  the  general  functions  of  TOS  as: 

...  an  on-line  real-time  automatic  data  processing 

system  designed  to: 

• Provide  information  to  the  commander  and  his 
staff  at  each  echelon  of  comma..  :pon  which 
estimates,  plans,  and  decision  will  be  based. 

• Assist  in  the  analysis  of  courses  of  action 
and  in  the  conduct  of  operations. 

• Provide  for  the  display  of  information  for 
staff  planning,  coordination  and  command 
decisions. 

• Reduce  the  reaction  time  of  the  command  and 
improve  the  accuracy,  timeliness,  and  dis- 
semination of  information  estimates,  plans, 
orders,  and  reports. 

• Enable  the  commander  and  staff  to  handle 
information  and  grasp  the  situation  at  an 
accelerated  rate,  thereby  speeding  decision- 
making and  increasing  control  over  tactical 
operations . 

• Permit  the  commander  to  act  rather  than  react. 

As  the  system  approaches  real-time  operations, 
its  performance  will  be  characterized  by  speed 
of  information  handling  and  processing  and 
accuracy  in  operations. 

TOS  is  currently  in  Advanced  Development.  It  is  scheduled  for  review 
by  the  Defense  Systems  Acquisition  Review  Council  (DSARC)  II  in  FY  1978  on 
entering  Engineering  Development.  The  history  of  TOS  is  discussed  in  the 
section  which  follows. 
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1 . TOS  Development  History 

The  Army  effort  in  tactical  automatic  data  processing  (ADP)  began 
in  1955  with  a study  which  identified  and  evaluated  approximately  100  separate 
tactical  ADP  applications.  In  December  1961,  a master  plan  for  the  Command 
Control  Information  System  - 1970  (CCIS-70)  program  was  published  which 
defined  the  approach  for  introduction  of  field  ADP. 

A program  review  in  1964  lead  to  program  reorientation  and  estab- 
lishment of  a new  command  for  development  (see  1965  on  Table  VII-1).  The 
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reoriented  program  provided  for  development  and  deployment  of  three  related 
but  semi -independent  systems:  TACFIRE,  TOS,  and  CS^. 

A significant  feature  of  TOS  development  is  the  large  number  of 
shifts  in  the  responsibility  of  developing  a tactical  operations  system. 
Table  VII-1  shows  the  Army  general  staff  and  program  management  respon- 
sibility assignments  since  the  start  of  the  overall  program. 


TABLE  VII-1 

TACTICAL  DATA  SYSTEM  RESPONSIBILITY  ASSIGNMENTS 


GENERAL  STAFF 


PROGRAM  MANAGEMENT 


1955 


1961  Deputy  Chief  of  Staff  - 
Operations  (DCSOPS) 

1962 


1963  Assistant  Chief  of  Staff  for 

Force  Development  (ACSFOR) 

1965 


1969  Assistant  Vice  Chief  of 
Staff  Army  (AVCSA) 

1970  Assistant  Chief  of  Staff  for 
Force  Development  (ACSFOR) 

1971 


1974  Chief  of  Research, 

Development  and  Acquisition 


U.S.  Continental  Army  Command 
(USCONARC) 


U.S.  Army  Material  Command 
(USAMC) 


Automatic  Data  Field  System 
Command  (ADFSC) 

U.S.  Army  Computer  Systems 
Command  (USACSC) 


U.S.  Army  Materiel  Command 
(USAMC) 
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In  the  period  of  1964  to  1969,  a prototype  tactical  operations  system 
(became  EURTOS)  was  developed  to  evaluate  the  feasibility  and  desirability 
of  TOS  for  the  field  army  at  the  army  level  and  below.  The  system  was 
tested  in  Europe  finishing  in  June  1969.  The  tests  involved  automating 
selected  functions  at  the  Army  Corps  and  division  levels.  The  hardware  for 
the  system  was  a van-mounted  Control  Data  Corporation  3300  computer.  The 
efforts  were  directed  toward  the  development  of  a system  for  the  Division 
and  its  subordinate  units.  In  1970,  the  EURTOS  hardware  and  software  pack- 
ages were  moved  to  Fort  Hood,  Texas  to  assist  in  the  definition  and  devel- 
opment of  requirements.  The  experimental  system  was  renamed  Development 
TOS  (DEVTOS).  After  several  tests  were  performed,  the  DEVTOS  was  evaluated 
as  having  accomplished  its  objectives  and  was  phased  out. 

The  current  TOS  program  was  started  in  1970  after  the  EURTOS  tests  were 
evaluated.  Requirement  analyses  were  performed  and  a series  of  General 
Officer  reviews  conducted.  The  result  was  a decision  to  develop  an  austere 
TOS  program  called  TOS  Operable  Segment  (TOS2).  TOS2  is  intended  to  operate 
as  a testbed  for  evaluation  of  concepts,  software,  and  hardware.  Specifi- 
cations were  prepared  followed  by  initiation  of  software  development  and 
hardware  procurement.  The  hardware  is  similar' to  TACFIRE  hardware. 

TOS  is  currently  oriented  toward  collection,  correlation,  retrieval, 
and  display  of  data  concerning  the  status  of  friendly  and  enemy  forces. 
However,  as  the  following  paragraph  from  Reference  3 indicates,  specific 
functions  have  not  been  determined  for  TOS. 

In  September  1974,  TRADOC  decided  to  recommend  a 
reorientation  of  the  TOS  program  (RTOS)  from  the 
initial  concept  described  in  the  ATACCOMAP,  pub- 
lished in  September  1972,  to  an  austere  stand- 
alone computer  system  concept.  The  basic  purpose 
of  TOS  remained:  "To  assist  the  commander  and  his 
staff  in  the  decisionmaking  process  by  providing 
information  which  is  more  timely,  more  accurate, 
more  complete,  and  more  available  in  a more  useful 
form  through  automatic  data  processing."  The  key 
change  was  to  limit  the  initial  application  of  ADP 
assistance  to  the  support  of  the  Division  Staff  only, 
and  provide  for  further  investigations  of  system 
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growth  potential  in  later  phases.  This  phased  intro- 
duction would  identify  the  requirements  for  the  initial 
application  and  present  them  to  ASARC  II/DSARC  II  for 
decisions  on  continuing  TOS  development,  and  procure- 
ment of  an  engineering  development  prototype.  Subse- 
quent phases  would  address  the  desired  expansions  of 
this  stand-alone  concept  in  terms  of  other  echelons 
and  other  applications.  HQDA  indicated  that  the  con- 
cept of  the  scaled  down  TOS  could  be  supported.  How- 
ever, the  description  of  TOS  must  await  the  results  of 
testing  and  analysis  of  various  alternatives. 


2.  Conroents  Concerning  TOS  Development 

As  is  indicated  in  the  previous  section,  specific  TOS  functions 
have  not  been  determined.  Discussions  with  individuals  who  have  knowledge 
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of  the  program  provide  these  responses  as  to  why  the  Army  has  not  been  able 
to  define  specific  TOS  functions: 

• Desire  to  over-automate.  Some  degree  of  conflict  exists 
between  those  who  believe  that  work  now  being  done  by  people 
could  be  better  done  by  automation  and  those  who  believe  that 
high  degrees  of  automation  are  riot  achievable  in  a practical 
sense.  Those  opposed  further  feel  chat,  if  a high  degree  of 
automation  were  achieved,  the  resulting  system  would  not  be 
as  effective  as  one  making  more  use  of  human  talents. 

• Organizational  problems.  One  specific  example  is  treatment 
of  uncertainty,  e.g.,  should  the  tactical  data  system  provide 
an  assessment  of  enemy  intentions  or  only  describe  enemy 
capabilities. 

• Frequent  changes  in  General  Staff  and  program  management 
responsibility.  For  any  system,  frequent  changes  would  be 
disruptive.  Since  evaluation  of  the  desirability  of  TOS 
capabilities  tends  to  be  rather  subjective,  frequent  res- 
ponsibility changes  tend  to  increase  difficulties  in  focus- 
ing on  a specific  set  of  TOS  capabilities. 

• Changing  Army  role.  Consideration  of  what  might  be  desirable 
in  a T05  system  started  shortly  after  World  War  II.  The 
Army  has  had  three  very  different  peacetime  periods  and  two 
very  different  "police  actions"  during  development  of  TOS 
requi rements . Since  the  specifics  of  the  Army  mission  changes, 
TOS  requirements  require  update  which  adds  another  layer  of 
difficulty  to  establishing  specific  requirements. 

• Basic  design  problems.  Even  in  the  most  benign  development 
environment,  it  is  not  an  easy  task  to  define  and  develop 
an  effective  decision  aid. 
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D.  CONCLUSION 


The  difficulties  encountered  by  the  Army  in  defining  system  requirements 
for  their  tactical  operations  systems  may  in  part  be  traced  to  their  revolu- 
tionary approach  to  system  development.  TACFIRE,  for  example,  is  an  entirely 
new  and  comprehensive  system.  It  supercedes  a much  simpler  system  which 
employed  a simple  computer  to  generate  weapon  aiming  data. 

The  Army's  revolutionary  approach  to  system  development  may  be  con- 
trasted with  the  Navy's  evolutionary  approach.  In  developing  combat  direc- 
tion systems,  for  example,  the  Navy's  approach  has  generally  been  to  automate 
functions  that  have  been  previously  performed  manually.  Where  new  functions 
are  added,  they  do  not  substantially  differ  from  the  functions  that  were 
performed  before.  The  Navy's  approach  considerably  simplifies  the  deter- 
mination of  system  requirements  and  also  simplifies  the  task  of  implementing 
the  modifications  to  the  system. 

The  ODAP  by  its  very  nature  tends  to  be  revolutionary  rather  than 
evolutionary.  To  avoid  the  type  of  problems  encountered  by  the  Army  in 
developing  their  tactical  operations  system,  the  ODAP  must  exercise  great 
care  and  extensive  preplanning  in  developing  the  operational  versions  of 
their  aids.  Many  of  the  recommendations  in  the  chapter  on  VTS— particularly 
those  relating  to  the  need  for  close  and  extended  interaction  between  sys- 
tem developers  and  users— seem  particularly  appropriate  to  the  ODAP. 
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VIII.  OTHER  ILLUSTRATIVF  SYSTEMS 


In  this  final  chapter  we  will  summarize  two  other  decision  aiding 
studies.  The  first  is  a review  of  the  current  decision  aiding  system  in 
the  National  Military  Command  Center;  the  second,  a mythical  Naval  soft- 
ware system.  These  studies  put  particular  emphasis  on  problems  encountered 
in  software  development.  As  a final  topic,  we  will  review  an  attempt  to 
apply  the  Von  Neumann-Morganstern  Utility  Theory  to  the  problem  of  assigning 
aircraft  to  an  attack  on  a Warsaw  Pact  airbase. 

A.  NATIONAL  MILITARY  COMMAND  CENTER  (NMCC) 

The  National  Military  Command  Center  is  the  primary  center  for  exer- 
cising the  command  and  control  of  United  States  military  forces.  Yet,  as 
LTC  Anthony  F.  Albright,  who  critiqued  the  current  (as  of  May  1975)  infor- 
mation system  for  the  center,  has  stated,  "There  is  no  effective  management 
information  system  ir,  the  NMCC  which  supports  the  decisionmaking  function." 

LTC  Albright  defines  the  role  of  an  MIS  as  one  of  providing  the  rig1.' 
information  in  the  right  format  at  the  right  time.  He  believes  the  current 
NMCC  system  fails  to  meet  this  requirement: 

• No  capability  exists  in  the  system  for  displaying  messages 
concurrently  at  multiple  locations. 

• Related  information  is  often  stored  in  separata  files,  thereby 
making  it  difficult  for  the  user  to  locate  the  information  he 
needs. 

• Information  retrievals  are  often  in  voluminous  outputs  making  it 
extremely  difficult  to  find  specific  data  needed  even  after  tla 
system  has  produced  the  required  report. 
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More  generally,  LTC  Albright  states: 

The  design  of  the  system  was  oriented  toward  system 
access  by  ADP  programming-oriented  personnel  rather 
than  operational  users.  The  programs  were  oriented 
toward  periodic,  fixed  format,  large  volume,  output 
reports  rather  thar,  the  selective,  quick  response, 
condensed  information  summaries  required  by  NMCC 
personnel  today. 

These  observations  by  LTC  Albright  emphasize  the  need  for  user-oriented 
rather  than  analyst-oriented  systems.  If  the  user  interfaces  are  not  devel- 
oped adequately,  potential  users  are  unlikely  to  employ  a systep.  This  was 
true  for  the  NMCC  system.  According  to  LTC  Albright,  the  selection  of  per- 
tinent data  and  the  assembly  and  summary  of  the  data  into  meam:vpul  infor- 
mation displays  are  currently  performed  manually  rather  than  though  the 
use  of  the  automated  system. 

LTC  Albright  next  defines  what  he  feels  are  the  requirements  of  an 
adequate  system  for  the  NMCC. 

The  NMCC  requires  a dedicated,  user-oriented,  inter- 
active MIS,  wh-fch  will  be  responsible  to  the  center's 
information  requirements  during  both  daily  (normal) 
operations  as  well  as  crises  management  operations. 

The  emphasis  on  both  daily  and  crises  management  operations  is  of 
particular  interest.  These  operational  roles  correspond  to  the  planning 
and  execution  phases  frequently  discussed  in  the  ODAP.  1 TC  Albright  further 
states : 


It  is  imperative  that  the  MIS  be  used  on  a daily 
basis  within  the  NMCC  and  not  be  reserved  for  -.rises 
management  situations.  In  addition  to  making  the  MIS 
that  much  more  effective  because  of  its  increased 
utilization,  such  an  employment  concept  insures  user 
familiarization  and  preclude  the  inevitable  disas- 
terous  introduction  of  an  ur-fsailiar  information 
processing  system  during  an  actual  crisis.  This  dual 
role,  or  flexibility  of  service,  requirement  which 
the  MIS  must  satisfy  is  not  unrealistic.  Experience 
within  the  NMCC  has  shov.i  that  the  operational  infor- 
mation needs  that  arise  d->  ing  normal  activities  are 
quite  similar  in  form  and  content  to  those  which  exist 
during  a crisis. 
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LTC  Albright  next  makes  a number  of  general  points  concerning  the 
selection  of  information  for  display  in  the  NMCC: 

t Sufficiency  of  information  is  not  necessarily  equivalent  to 

volume  of  information.  Or  more  simply  put,  it  is  not  neces- 
sarily true  that  the  more  information  you  have  the  better  off 
you  are. 

9 Selection  of  information  should  be  based  on  requirements,  not 
on  availability. 

• In  a crisis  situation,  there  is  a need  for  less  information  but 
for  more  carefully  selected  information  than  in  normal  operations 

LTC  Albright  recommends  NMCC  follow  the  current  trend  in  computer 
system  design: 

Advancing  technology  has  ...  led  to  a trend  toward 
using  networks  of  minicomputers  to  perform  specific 
functional  tasks  rather  than  employing  large,  more 
powerful,  central  computers  . . . (minicomputers)  have 
demonstrated  extremely  powerful  performance  in  acting 
as  front  end  processors  and  devices  to  interface  CRT 
displays  to  C^  systems  . . . (the  use  of  minicomputers 
to  support  integrated  display  techniques)  would  be  in 
accord  with  the  latest  ADP  industry  thinking  which  favors 
the  use  of  large  scale  computers  to  store  and  manipulate 
data  bases  and  minicomputers  to  control  the  communication 
and  display  of  processed  data. 

If  NMCC  were  to  follow  this  trend,  LTC  Albright  suggests  that  plasma 
technology  might  then  provide  the  key  to  the  display  of  multisource  data. 

A plasma  "panel"  would  be  located  on  the  face  of  a CRT  display.  A viewer 
observing  this  CRT/plasma  panel  display  would  see  two  superimposed  images, 
each  of  which  is  driven  by  a separate  minicomputer.  If  this  proves  to  be 
a viable  approach,  incompatible  data  stream  would  then  never  need  to  be 
physically  combined  at  all,  but  could  merely  be  superimposed  on  a common 
display  for  viewing  by  a decisionmaker. 
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B.  THE  MUDD  REPORT : A CASE  STUDY  OF  NAVY  SOFTWARE  DEVELOPMENT  PRACTICES 


MUDD—the  Multisource  Unified  Data  Distribution  System--!' s a mythical 
software  system  whose  development  is  chronicled  in  a report  by  David  M. 

Weiss  of  the  Naval  Research  Laboratory.  The  report  is  based  on  extensive 
interviews  conducted  by  Mr.  Weiss  with  people  responsible  for  the  development 
of  software  for  the  Navy.  As  its  theme,  it  highlights  the  typical  problems 
and  pitfalls  encountered  in  software  system  development  and  recommends 
procedures  that  would  be  useful  to  developers  in  avoiding  them.  The  MUDD 
report  complements  this  one  in  that  it  concentrates  on  the  purely  software 
problems  of  system  development— design,  structure,  test  and  evaluation, 
maintenance,  and  the  more  general  problems  relating  to  assignment  of  respon- 
sibility and  definition  of  requirements . 


We  will  briefly  describe  the  MUDD  system,  its  origin  and  development, 
and  tnen  list  some  of  the  r ’commendations  of  the  report.  Many  are  similar 
to  recommendations  made  in  this  report. 

The  events  leading  to  the  development  of  the  MUDD  system  occurred  when 
a submarine  was  reported  cruising  in  an  area  thought  to  be  fr»e  of  hostile 
forces.  In  the  course  of  reacting  to  the  report,  the  cognizant  commander 
requested  information  on  the  disposition  of  all  forces  in  the  area.  The 
information  was  received  far  past  the  time  it  would  have  been  useful.  As 
a consequence  of  this  incident,  a committee  was  formed  which  spent  several 
months  studying  ways  of  consolidating  the  collection  and  distribution  of 
tactical  information.  It  decided  that  a new  system  was  required,  which 
would  consist  of  individually-tailored,  information-gathering  facilities 
aboard  each  ship,  and  a central  land-based  computer  to  maintain  all  tac- 
tical data  and  produce  it  on  demand.  The  committee  also  decided  intel- 
ligence data  should  be  included  in  the  system,  in  addition  to  tactical  data, 
thereby  requiring  the  system  to  communicate  with  other  intelligence  systems, 
some  still  in  the  predevelopment  stages. 

Before  disbanding,  the  committee  had  one  major  decision  to  make:  who 
should  be  responsible  for  developing  MUDD.  This  proved  to  be  a major  prob- 
lem. It  was  eventually  resolved  in  the  following  way:  the  system  divided 
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naturally  into  an  information  gathering  and  an  information  distribution 
part.  The  information  gathering  activities  were  primarily  concerned  with 
fleet  operations  and  were  therefore  assigned  to  one  of  the  fleet  groups. 

The  information  distributions  activities  were  more  closely  related  to  intel 
ligence  groups.  The  committee  therefore  divided  responsibility  for  the 
development  of  the  system  between  the  two  groups.  During  the  subsequent 
development  of  the  system,  many  problems  were  encountered,  including  those 
described  below: 
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• The  developers  were  compelled  to  use  the  Navy's  AN/UYK-7  computer. 
The  only  high-level  language  available  on  the  system  was  CMS-2. 
FORTRAN,  COBOL,  ALGOL,  and  PL/1  were  not  available.  The  shore- 
based  subsystem— known  as  the  Data  Use  and  Maintenance  System 

( DUMS ) — was  later  forced  to  switch  to  the  WWMCCS  Honeywell  com- 
puter. Since  this  computer  did  not  have  a CMS-2  compiler,  all 
programming  written  up  to  that  point  had  to  be  discarded  and  pro- 
gramming personnel  retrained  or  replaced.  Moreover,  the  support 
software  was  inadequate  for  development  of  the  ship-based  system 
which  continued  to  use  the  AN/UYK-7  computer. 

« The  ship-based  subsystem— known  as  the  Ship  Information  Processing 
System  (SIPS)— encountered  extensive  problems  because  every  ship 
class  under  development  had  a different  version  of  every  major 
module  in  the  system.  Each  required  its  own  documentation. 

t The  contractor  on  SIPS  was  originally  chosen  by  a low-bidder 
procedure  which  selected  the  (technically  qualified)  contractor 
with  the  lowest  average  cost  rate  per  programmer.  The  contractor 
maintained  his  low  rates  by  hiring  three  experienced  programmer- 
designers  at  high  salaries  and  a number  of  inexperienced  program- 
mers at  low  salaries.  The  experienced  personnel  eventually  left 
the  contract. 

• The  Critical  Design  Reviews  (CDR)  of  the  system  were  essentially 
just  tutorials  of  the  system.  The  CDR  for  the  shore-based  system 
lasted  only  about  3 hours.  No  really  critical  review  was  held. 

This  led  to  extensive  problems  later  in  the  development. 

• In  the  test  and  evaluation  phase,  the  end  users  of  the  system  (who 
had  not  been  consulted  since  the  CDRs 1 ) , now  that  they  had  a chance 
to  observe  it  in  operation,  wanted  it  modified.  Those  with  the 
most  complaints  were  the  intelligence  analysts  and  operational 
commanders.  They  were  not  receiving  the  data  they  needed.  For 
example,  an  operational  commander  could  easily  obtain  a list  of 
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all  hostile  ships  which  entered  or  left  an  area  within  the  last 
week— information  of  particular  interest  to  the  intelligence 
analyst— but  could  not  obtain  a list  of  hostile  ships  currently 
in  the  area.  This  appeared  to  be  a direct  consequence  of  the 
division  of  responsibility  for  the  system  and  the  resulting  lack 
of  communication  between  the  two  groups. 

The  subsystem  required  extensive  maintenance.  After  about  4 months, 
the  level  of  effort  stabilized  at  about  30  percent  of  the  level  required 
during  coding.  This  was  partly  due  to  the  large  number  of  versions  of  the 
individual  modules  in  the  ship-based  system.  More  significant,  perhaps,  was 
the  interdependence  of  the  modules  and  the  lack  of  standarized  interfaces 
between  modules  (so  called,  information  hiding).  For  example,  the  developers 
of  one  module,  knowing  that  the  developer  of  another  module  had  stored  infor- 
mation they  required  at  a certain  point  and  form  on  a disk,  would  access  it 
directly  rather  than  through  a standardized  interface.  Thus,  changes  in  one 
module  affected  the  performance  of  other  modules. 

As  a consequence  of  these  and  other  problems,  the  MUDD  system  incurred 
a time  overrun  of  100  percent  and  a cost  overrun  of  150  percent. 

Mr.  Weiss  at  the  conclusion  of  his  report  on  the  MUDD  system  presents 
a number  of  recommendations  for  future  system  development.  We  repeat  a 
number  of  them  here. 

• Unify  life-cycle  control  of  software.  Development  responsibility 
for  a system  should  not  be  split  and  maintenance  activity  should 
not  be  independent  of  development  activity.  In  particular,  system 
maintainers  should  participate  in  the  development  cycle  from 
requirements  definitions  to  delivery.  Separation  of  control  over 
software  during  its  lifetime  leads  to  additional  interfaces  and 
inhibits  feedback  useful  for  preventing  repetition  of  errors. 

• Require  the  participation  of  system  users  in  the  development  cycles 
from  the  time  requirements  are  established  until  the  time  the  sys- 
tem is  delivered.  MUDD  users  never  saw  the  system  until  operational 
test  and  evaluation.  Many  of  the  modifications  they  then  requested 
could  not  be  implemented  because  the  changes  were  too  costly. 

Changes  which  are  inexpensive  and  easy  to  implement  at  system 
testing  time  are  often  extremely  expensive  and  difficult  to  imple- 
ment after  the  software  has  been  written. 
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• Write  acceptance  criteria  into  software  development  contracts. 

Both  the  contracting  agency  and  the  contractor  then  have  a clear 
idea  of  the  requirements  the  system  must  meet  to  be  accepted.  If 
the  criteria  are  not  clearly  established  in  the  contract,  there  may 
be  a misunderstanding  and  a protracted  delay  for  negotiation  before 
the  system  is  delivered. 

• Develop  software  on  a system  that  provides  good  support  capabilities. 
If  necessary,  consider  developing  support  software  prior  to  or  in 
conjunction  with  system  development.  Most  support  software  is  a 
good  example  of  sharable  software.  The  DUMS  developers  were  con- 
siderably aided  by  the  presence  of  support  software,  and  the  SDS 
developers  were  sorely  in  need  of  it.  Support  software  included 
assemblers,  compilers,  operating  systems,  text  editors,  and  man- 
agement information  systems. 

• Allocate  development  time  properly  among  design,  coding,  and 
checkout.  Software  development  experience  Indicates  that  rough 
estimates  for  these  phases  are  40  percent  for  design,  20  percent 
for  coding  and  40  percent  for  checkout.  Some  of  the  variables 
•‘nvolved  are  the  nature  of  the  project,  the  design  models  available 
for  the  project,  and  the  experience  of  the  designers.  All  devel- 
opers should  keep  a file  of  past  experience  of  the  designers. 

All  developers  should  keep  a file  of  past  experience  in  this  area 
for  future  guidance.  Since  manpower-allocation  estimates  are 
based  in  part  on  the  time  estimates  for  the  different  phases  of 
development,  improper  estimation  can  be  quite  expensive. 

• Use  state-of-the-art  design  principles  such  as  information  hiding. 
Large  systems,  such  as  the  ship-based  subsystem  of  MUDD,  must  be 
designed  using  principles  that  optimize  the  chances  for  producing 
reliable,  inexpensive,  maintainable  software.  The  resulting 
design  may  even  seem  unnatural  to  designers  accustomed  to  opti- 
mizing for  efficiency.  Ignorance  of  information  hiding  helped 
produce  a MUDD  system  that  was  expensive,  late,  unreliable,  and 
difficult  (and  sometimes  impossible)  to  improve  or  maintain.  The 
basic  problem  in  MUDD  was  that  each  module  took  advantage  of 
implementation  decisions  made  in  other  modules.  A change  to  one 
module  then  started  a chain  reaction  of  changes  in  other  modules. 
Naturally,  the  l.arger  the  .number  of  changes  required,  the  lower 
the  probability  and  the  higher  the  expense  of  correctly  implement- 
ing a modification  to  the  system. 

The  software  design  should  isolate  and  insulate  all  areas  where 
requirements  are  most  likely  to  change.  In  particular,  all  inter- 
faces with  other  systems  over  which  the  developers  and  users  have 
no  control  should  be  transparent  to  the  rest  of  the  system.  Data 
obtained  from  other  systems  can  change  in  format  in  unpredicted 
and  unheralded  ways.  Often  the  only  recourse  in  such  situations  is 
to  change  the  module  which  inputs  the  data.  A change  of  this  nature 


r! 


U 


i 


i 


% 


m 


I 

I 

I 

I 

I 

I 

I 

I 


should  not  require  a change  to  more  than  one  module.  This  is  an 
important  instance  of  the  need  for  information  hiding. 

• Critical  design  reviews  should  be  active  reviews  and  not  passive 
tutoria~TiT  Sufficient  time  must  be  allowed  to  read  design  doc- 
uments  before  the  review,  and  the  documents  must  be  readable. 
Alternative  design  decisions  and  the  reasons  for  eliminating  them 
should  be  discussed.  In  addition  no  code  should  be  written  until 
the  design  is  approved.  The  critical  design  review  is  the  last 
and  most  important  time  to  catch  errors  before  coding  starts. 

Once  code  has  benn  written,  any  design  change  involves  at  least 
examining  all  existing  code  for  the  impact  of  the  change  and  may 
involve  discarding  and  modifying  code.  System  progress  is  delayed 
during  this  process.  Consequently  the  cost  of  a design  change 
during  coding  may  be  2 or  3 times  the  cost  of  the  change  before 
coding.  The  multiplier  becomes  larger  the  farther  the  system 
progresses  in  the  development  cycle. 

• Ensrre  that  a proper  variety  of  test  data  is  used.  The  differing 
MUDD  experience  between  system  integration  and  test  and  evaluation 
is  indicative  of  some  of  the  problems  that  arise  when  a system 

is  incompletely  tested.  Support  software  capable  of  monitoring 
system  tests  and  reporting  on  failure  and  on  what  code  has  and  has 
not  been  tested  is  not  coming  into  use.  Test  data  can  be  gener- 
ated by  use  of  a simulator.  Although  testing  cannot  by  itself 
be  used  to  guarantee  reliability,  it  will  probably  remain  for  some 
time  to  come  as  the  basis  for  finding  errors  and  nspiring  con- 
fidence in  the  systems. 

• Maintain  current  complete  documentation.  Documentation  is  an 
often  neglected  part  of  software  development.  In  many  systems,  it 
is  done  on  an  after-the-fact  basis  and  rarely  updated.  This  may 
be  because  no  one  knows  how  to  do  it  properly.  Unreliable  doc- 
umentation forces  the  maintenance  programmer  to  rely  on  nothing 
but  code  reading,  a long  and  tedious  process  for  his  understanding 
of  the  system.  Well -written  documentation  will  have  few  redun- 
dancies and  many  cross-references;  it  will  be  tailored  to  suit  the 
system  being  documented.  One  sure  sign  of  danger  is  when  coders 
use  unofficial  documents  and  produce  the  official  ones  only 
because  of  contract  requirements. 
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C.  ATTACKING  HARDENED  AIR  BASES  (AHAB) 


The  primary  emphasis  in  this  report  has  been  on  operational  decision 
aids  and  decision  systems.  Attention  has  also  been  focused  on  systems  like 
SIMTOS,  which  are  simulators  used  to  study  the  decisionmaking  process  in 
an  operational  setting,  and  on  such  semi-theoretical  work  as  Honeywell's 
studies  of  decision  style.  Little  attention  has  thus  far  been  given  to 
sophisticated  mathematical  techniques  that  appear  promising  for  operational 
use.  Partly,  this  is  because  much  of  the  potentially  useful  work  is  or  has 
been  conducted  by  ONR  and  is  described  elsewhere.  Partly,  it  is  because 
much  of  the  work  must  undergo  a considerable  amount  of  additional  develop- 
ment to  be  operationally  useful.  Nevertheless,  several  interesting  attempts 
have  been  made  to  apply  sophisticated  mathematical  techniques  to  operational 
decision  problems. 

A particularly  interesting  and  representative  example  of  the  application 
of  mathematical  aids  to  operational  decisionmaking  is  the  AHAB  computer 
program,  unde'.'  the  auspices  of  the  United  States  Air  Force  Project  Rand. 

AHAB  represents  an  attempt  to  use  Von  Neumann-Morgenstern  Utility  Theory 
to  assist  tactical  decisionmakers  in  planning  an  air  strike  against  a 
Warsaw  Pact  airbase.  It  allows  the  user  to  explore  the  consequences  of 
adopting  a variety  of  tactics  for  attacking  the  airbase.  Pertinent  variables 
considered  in  AHAB  are:  (1)  the  number  of  enemy  aircraft  destroyed,  (2) 
the  number  of  aircraft  shelters  or  hangarettes  destroyed,  (3)  the  number  of 
hours  the  runway  system  is  closed  and  (4)  the  number  of  friendly  aircraft 
lost  in  the  strike. 

AHAB  is  a Monte  Carlo  simulation  model.  Repeated  trials  of  an  attack 
on  the  airbase  are  made  with  the  outcomes  of  stochastic  events  on  each  trial  — 
such  as  the  destruction  of  a friendly  aircraft— being  determined  by  comparing 
a random  number  drawn  from  an  appropriate  probability  distribution  to  a 
probability  of  kill,  which  is  input  to  the  model.  The  expected  utility 
of  the  attack  is  calculated  by  averaging  over  the  utilities  of  each  trial. 

The  model  does  not  contain  an  algorithm  for  selecting  tactics  that  maximize 
utility,  but  rather  the  user  must  explore  the  utility  space  by  repeatedly 


running  the  model  for  alternative  tactics.  This  does  not  limit  the  potential 
usefulness  of  the  model  or  the  concepts,  however,  for  an  optimization  algo- 
rithm could  always  be  added  to  the  model. 

The  heart  of  the  AHAB  model  is  the  Von  Neumann-Morganstern  utility  func- 
tion, which  is  used  as  an  objective  function  or  measure  of  effectiveness  for 
evaluating  alternative  tactics  by  the  commander.  In  this  section  we  will 
assume  the  reader  is  familiar  with  the  general  idea  of  utility  theory  and 
we  therefore  plan  only  to  indicate,  using  AHAB,  how  the  theory  is  typically 
applied  in  practice.  AHAB  assumes  the  utility  function  is  additive  so  that 
it  may  be  used  in  this  form: 


U(x-| , Xg,  Xg,  s4)  - A-jU^x-j)  + ^2U2^X2^  X3U3 ^x3 ^ * ^4^4^*4^ 

where  the  variables  x-j , Xg,  Xg,  and  x^,  refer  in  AHAB  to  the  four  variables 
discussed  earlier,  i.e.,  the  number  of  enemy  aircraft  destroyed,  the  number 
of  hangarettes  destroyed,  and  so  forth.  The  A. 's  are  weighting  coefficients 
representing  the  relative  importance  of  the  four  factors. 

Use  of  the  additive  theory  greatly  simplifies  the  determination  of  the 
utility  function,  because  each  of  the  four  component  utility  functions  can 
be  constructed  separately.  Using  the  BRLT  (Basic  Reference  Lottery  Ticket) 
method,  and  considering,  for  example,  the  first  utility  function  u-j  (x^ ) , 
set  the  value  of  the  function  to  one  at  a value  of  x-j  corresponding  to  all 
enemy  aircraft  destroyed.  This  is  the  best  possible  outcome.  Similarly, 
set  the  value  of  the  function  to  zero  for  a value  of  x-j  corresponding  to  no 
aircraft  destroyed.  This  is  the  worst  possible  outcome.  Then  determine 
from  the  decisionmaker  what  certain  outcome— i .e. , number  of  planes  des- 
troyed—is  equally  preferable  to  a lottery  -'n  which  all  planes  are  destroyed 
with  a probability  of  50  percent  and  no  planes  are  destroyed  with  a prob- 
ability of  50  percent.  Assign  this  outcome  a utility  of  0.5.  Continue  this 
halfing  process  to  the  desired  degree  of  refinement  (iri  AHAB  the  program 
locates  nine  points  in  this  manner).  Intermediate  values  of  the  utility 
function  are  found  by  linearly  interpolating  between  these  points. 
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The  procedure  for  obtaining  the  weighting  factors  is  equally 
straightforward.  Let  be  the  best  possible  value  for  the  variable  i 
and  w^  the  worst  possible  value.  Consider  the  four  situations: 

$1  • (b-j . w2 , w3 , w4) 

Sg  : (w-j , b2»  w3,  w4) 

S3  : ( W-j , w3,  b3>  w4) 

^4  • (w-j » v#2 » w3  j b^)  . 

Note  that 

U(Si)  = X.. 

Ask  the  decisionmaker  which  of  the  four  situations  he  prefers.  Sup- 
pose he  selects  S^.  Then  ask  him  what  level  of  x4  makes  (w-j , w2,  w3,  x4) 
equally  preferable  to  S-j . If  he  selects  x4,  then 

^4U(x4)  = X-j . 

Repeating  the  process  for  $2  and  S3  yields  three  equations  in  four  unknowns. 
Adding  a normalization  condition  on  the  X..S— which  is  equivalent  to  multiply- 
ing the  utility  function  by  a positive  constant— allows  the  x.s  to  be  deter- 
• 1 

mined  uniquely.  This  completes  the  determination  of  the  utility  function. 

The  use  of  additive  utility  functions  imposes  two  potentially  restric- 
tive limitations  on  the  flexibility  of  utility  theory  to  reflect  the  decision 
maker's  value  system.  These  are  commonly  known  as  preferential  and  utility 
independence.  In  preferential  independence  the  tradeoff  between  any  two  var- 
iables for  constant  utility  must  be  independent  of  the  value  of  any  third 
variable.  For  example,  the  number  of  friendly  aircraft  a decisionmaker  is 
willing  to  lose  in  order  to  destroy  a given  number  of  enemy  aircraft  may  not 
depend  on  the  number  of  hangarettes  destroyed  or  the  time  the  runway  is  out 
of  operation. 


Utility  independence  implies  that  the  marginal  utility  of  any  variable 
is  a function  of  that  variable  alone.  For  example,  for  this  condition  to 
be  met,  the  loss  in  utility  associated  with  losing  a friendly  aircraft 
must  be  independent  of  the  number  of  enemy  aircraft  already  destroyed.  In 
general,  the  condition  thus  severely  limits  the  use  of  the  additive  utility 
theory.  In  a situation  like  AHAB,  however,  where  tr.e  attack  is  conducted 
against  only  a single  airbase,  involving  only  a small  portion  of  the  total 
forces  of  both  sides,  the  limitation  is  probably  not  overrestrictive. 

The  AHAB  model  has  not  been  tested  in  an  operational  environment  but 
has  been  used  principally  as  a research  tool  to  explore  the  potential  use 
of  utility  theory  in  decisionmaking.  Air  Force  officers,  who  were  shown 
the  system,  found  the  concepts  attractive  and  felt  that  a more  comprehensive 
model  might  have  some  practical  significance.  The  model  might,  for  example, 
speed  up  the  decision  process  and  produce  more  consistent  results.  Whether 
this  is  correct,  however,  remains  an  open  question. 
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F.  Prokowki,  Methods  for  Analysis  of  Fleet  Tactical  Effectiveness 
and  Performance  (MAFTEP),  TRW  Report  No.  1 7531 -MOOT -TQ-QO.  1972, 
UNCLASSIFIED. 

G.  E.  Pugh,  Mathematical  Decision  Aids  for  the  Task-Force  Commander 
and  His  Staff,  General  Research  Corporation.  593W-01-CR.  January  1976. 
UNCLASSIFIED. 

Milton  Leroy  Senft,  Adaptive  Logic  Techniques  and  Decision-Making, 

Naval  Postgraduate  School,  March  1975,  UNCLASSIFIED. 

Alan  Sicherman,  An  Interactive  Computer  Program  for  Assessing  and 
Using  Multiattribute  Utility  Functions,  Massachusetts  Institute  of 
Technology,  June  1975,  UNCLASSIFIED. 

R.  A.  Singer,  R.  C.  Sea  and  K.  B.  Housewright,  "Derivation  and 
Evaluation  of  Improved  Tracking  Filters  for  Use  in  Defense  Multitarget 
Environments,"  IEEE  Transactions  on  Information  Theory,  Volume  IT-20, 

No.  3,  July  1974,  UNCLASSIFIED. 

P.  Slovic  and  A.  Tversky,  Who  Accepts  Savage's  Aniom,  Oregon  Research 
Institute,  February  1974,  UNCLASSIFIED. 

J.  W.  Ulvila,  A Pilot  Survey  of  Computer  Programs  for  Decision 
Analysis,  Decisions  and  Designs,  Inc.,  Technical  Report  75-2, 

January  1975,  UNCLASSIFIED. 

R.  L.  Weisbrod,  K.  B.  Davis,  A.  Freedy  and  G.  Weltman,  Adaptive  Computer 
Aiding  in  Dynamic  Decision  Processes:  An  Initial  Study  of  Dynamic 
Utility  Convergence  and  Decision  Aiding,  Perceptronics,  Inc., 

PTR-1 01 6-74-11 , November  1974,  UNCLASSIFIED. 

Detlof  V.  Winterfel dt  and  Gregory  W.  Fischer,  Multiattribute  Utility 
Theory:  Models  and  Assessment  Procedures,  Michigan  University, 

November  1973,  UNCLASSIFIED. 

Detlof  V.  Winterfel dt,  An  Overview,  Integration,  and  Evaluation  of 
Utility  Theory  for  Decision  Analysis,  University  of  Southern  California, 
August  1975,  UNCLASSIFIED. 

P.  L.  Yu  and  G.  Leitmann,  Nondominated  Decisions  and  Cone  Convexity 
in  Dynamic  Multi criteria  Decision  Problems,  Texas  University, 

October  1973,  UNCLASSIFIED. 

Selected  papers  from  1976  IEEE  Conference  on  Avionics.  Topic  - 
Digital  Avionics  Information  System  (DAIS),  UNCLASSIFIED. 
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GENERAL/MISCELLANEOUS 


1.  Bibliography  of  Operational  Decision  Aiding  Program,  August  1976. 

2.  Department  of  the  Navy,  The  Navy  Decision  Coordinating  Paper  (NDCP) 
for  Operational  Decision  Aids,  enclosure  to  letter  from  Chief  of 
Naval  Operations  to  Chief  of  Naval  Research,  8 July  1976,  UNCLASSIFIED. 

3.  Office  of  Naval  Research,  Psychological  Sciences  Division  FY  1976 
Programs,  No.  450-8,  March  1976,  UNCLASSIFIED. 

4.  Jan  Ruff,  Survey  of  Work  Units  Concerned  with  Operational  Decision 
Making  and  Theory,  System  Planning  Corporation,  29  June  1976, 
UNCLASSIFIED. 

Note:  Although  classified  sources  are  referenced,  only  unclassified 
data  from  these  sources  were  used  in  the  preparation  of  this 
report. 
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SYSTEM  PLANNING  CORPORATION 

1500  Wilson  Boulevard  • Suite  1500  • Arlington,  Virginia  22209  • (703)  841-2800 


MEMORANDUM  TO  DISTRIBUTION 


Subject:  Errata  Sheet  to  System  Planning  Corporation  Report  312 

Reference:  "An  Investigation  of  Operational  Decision  Aids,"  written 
by  Gary  L.  Lucas  and  Jan  A.  Ruff,  dated  2 July  1977 


The  following  changes  should  be  incorporated  into  the  referenced 
report. 


Page 


Within  the  present  Amy  structure,  the  intelligence  branch 
is  responsible  for  surveillance;  the  artillery  branch,  for  target 
acquisition.  Hence,  the  roles  of  SOTAS  cross  current  organiza- 
tional lines.  Consequently,  in  developing  SOTAS,  continual  review 
of  existing  procedures  and  practices  for  conveying  information 
between  organizational  elements  was  needed  to  ensure  that  proce- 
dural delays  could  be  eliminated  and  that  the  advantages  of  the 
automated  system  would  be  realized. 

Delete  from  line  5 

and  the  performance  of  the  system  decreased. 

Delete  from  last  2 sentences 

By  being  positioned  behind  the  FEBA,  it  is  relatively  invulnerable 
to  ground  fire  and  because  of  the  tracker. 
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